Paul Sandoz wrote:
> Hi Frank, Craig,
>
> Do you think it would be useful to have support for the case of
> dispatching to Jersey and if the request is not dispatched then it is
> dispatched to Spring?
>
> Craig, what would be the best way to utilize the Servlet-based
> components in this respect, as filters? does it make sense to split
> out Jersey config functionality using some context?
>
Having thought about this only briefly so far (it's back-to-work day for
lots of Sun folks, so need to get back into this "thinking" mindset :-),
there are a couple of gotchas to think about with respect to servlet
mappings:
* The syntax for matching patterns (for either servlets or filters)
is pretty limited ... you basically get a fixed string, a tail match
("/foo/*"), or an extension match ("*.foo"), where the "*" cannot
include a slash character. This *may* be getting addressed in
the Servlet 3.0 effort currently underway, but that won't help
us in the mean time.
* Many (all?) servlet containers rely on a "default" servlet that is
implicitly mapped to "/*" with a lower priority than any other
servlet, to serve static resources like images, stylesheets, and
javascript files. If we interpose a filter mapped to "/*" we'll have
to deal with this as well -- and solutions are likely to be
container specific, which is not usually a good thing.
It's not clear to me that there is a lot of value in interposing another
layer of dispatching, when the container itself already knows how to do
that (albeit within limits on the mapping syntax), unless we rub up
against the mapping limits. One can also just split the RESTful calls
out into a separate webapp (they shouldn't be sharing any session state
with non-RESTful calls, right? :-).
Craig
> Paul.
>
> On Jan 3, 2009, at 1:24 AM, Craig McClanahan wrote:
>
>> Frank McLean wrote:
>>> 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
>>> <http://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
>>>
>>>
>> This kind of question would indeed be welcome on the user list, as
>> it's about *using* Jersey instead of developing it :-).
>>
>> Your approach will work, as long as the "*.htm" pattern covers *all*
>> the resources you would ever want to have returned via Spring MVC,
>> and you'll *never* want such a call to go through Jersey instead.
>> That of course depends on your application requirements, but it seems
>> like something I could live with using this combination of technologies.
>>
>> Craig
>>
>