dev@jersey.java.net

Combining Jersey and non-Jersey on one webapp

From: Frank McLean <Frank_McLean_at_natureserve.org>
Date: Fri, 2 Jan 2009 10:53:03 -0500

Hi,

This is kind of a user question, but I think only a developer could answer it. My apologies if this is not the case.

I have a project using Spring MVC to which I would like to add some services. I have had trouble separating the 2 'streams' - either all requests are taken by Spring MVC or all by Jersey (usually the latter). After reading a lot and much trial and error, the following web.xml seems to do the trick:

      <servlet>
            <servlet-name>springmvc</servlet-name>
            <servlet-class>
                  org.springframework.web.servlet.DispatcherServlet
            </servlet-class>
            <load-on-startup>1</load-on-startup>
      </servlet>

      <servlet>
            <servlet-name>jersey</servlet-name>
            <servlet-class>
                  com.sun.jersey.spi.container.servlet.ServletContainer
            </servlet-class>
            <load-on-startup>2</load-on-startup>
      </servlet>

      <servlet-mapping>
            <servlet-name>springmvc</servlet-name>
            <url-pattern>*.htm</url-pattern>
      </servlet-mapping>

      <servlet-mapping>
            <servlet-name>jersey</servlet-name>
            <url-pattern>/myservices/*</url-pattern>
      </servlet-mapping>

The only thing I have to remember in this situation is that the servlet-mapping for 'jersey' effectively creates a new 'context root', so that if I have a resource class as follows:

@Path("/services/test")
public class TestService {

      @GET
      @Produces("text/plain")
      @Path("dosomething")
      public String someMethod(etc...)

Rather than having the service as -

http://myhost/mywebapp/services/test/dosomething

I have to use -

http://myhost/mywebapp/myservices/services/test/dosomething

Once I do that, all is well.

OK, so, my question is: Is this a valid approach, or a kludge? Am I skating on thin ice, simply exploiting a 'feature' of the implementation which may at some point be refactored away?

Thanks for your time,

Frank McLean