Re: [Httpunit-develop] Re: [Httpunit-develop] A ccessing web.xml from unit tests? getResource AsStream…

On Apr 17, 2006, at 9:59 AM, Russell Gold wrote:

> On Apr 14, 2006, at 6:59 PM, Gordon Henriksen wrote:
>
>> And it worked fine under Eclipse, but then I went to mvn test  
>> before committing; to my disappointment, Maven runs the unit tests  
>> relative to the parent pom, more often than not, so I can't use a  
>> relative path. After some research I tried this instead:
>>
>>     new ServletRunner(Thread.getContextClassLoader 
>> ().getResourceAsStream("/WEB-INF/web.xml"), "/context");
>
> That shouldn't work since the path /WEB-INF is probably not in your  
> class path. You need something that is in your class path and that  
> has a known relationship to the location of your WEB-INF  
> directory.  If you don't want to use the system property route, if  
> you tell me your directory and classpath setup, I may be able to  
> suggest an alternative.

Yes, I can see how that's true until the warfile is packed. Maven  
does assemble resource-resources on the classpath for the test phase,  
but does not assemble webapp resources, which don't get integrated  
into the build until the warfile is actually built. I'll try seeing  
if I can stuff web.xml into src/main/resources so that it's available  
as a resource at test time. I think maven-eclipse-plugin informs  
Eclipse of resource directories so that it can behave accordingly.

Thanks for the redirect; this should be useful if I decide to pursue  
this.


Nevertheless, I think I'm going to skip trying to load web.xml for  
the time being; I need a means of dependency injection for tests, and  
loading web.xml makes me go to some other configuration point to get  
that done. Rather, I'll route servlet requests through an interceptor  
servlet that I can use as a component assembler—letting me skip the  
whole IOC microkernel thing that's sure to make my co-workers' heads  
explode. Here's an example:

     〜 src/test/java/net/myorg/BaseServlet.java 〜
     package net.myorg;
     public abstract class BaseAssemblyServlet extends HttpServlet {
         ISomeServlet someServlet;
         public void init() {
             someServlet = new SomeServlet();
             someServlet.setSomeService(getSomeService());
             someServlet.init();
         }
         public void service(HttpRequest req, HttpResponse res)  
throws IOException, ServletException {
             if ("/some-servlet".equals(req.getPathInfo())
                 someServlet.service(req, res);
             else
                 res.sendError(404, "File Not Found");
         }
         public abstract ISomeService getSomeService();
     }

     〜 src/test/java/net/myorg/TestServlet.java 〜
     package net.myorg;
     /**
      * Production servlet, using real SomeService.
      */
     public class DeploymentServlet extends BaseAssemblyServlet {
         ISomeService someService = new SomeService();
         @Override public abstract SomeService getSomeService()  
{ return dataSource; }
     }

Under test, I'll provide different overrides for the builder methods:

     〜 src/test/java/net/myorg/TestServlet.java 〜
     package net.myorg;
     /**
      * One possible test servlet, using a MockSomeService.
      */
     public class SomeMockServlet extends BaseAssemblyServlet {
         ISomeService someService = new MockSomeService();
         @Override public abstract SomeService getSomeService()  
{ return dataSource; }
     }

This isn't so high-maintenance as it seems, since I had to implement  
request routing to manage the virtual URL space we're using anyhow.

And, unlike an IOC container, my co-workers already know Java, so I  
think it'll work well for a while.

— G