Hi Paul, Justin, Craig,
Thanks for your responses. Craig, thanks for being gentle on my 'user' question. :)
Just to close this out - I may be worrying unnecessarily, but I was finding solutions to my problem that involved custom filters and request dispatchers and whatnot. My way seems a lot simpler, so I was trying to get at whether my approach was a long term valid one, rather than a 'workaround' - I know it works (at least on Tomcat 5.5).
If someone asks this same question on the user list, can I tell them 'Just make your Jersey servlet mapping something like "/services/rest/v1_01/*" (or whatever) and remember that this will need to be prepended to all your service URL calls. Your annotated resource @Paths will then hang off that root.'? If so, I shall be happy to give said advice. :)
Thanks for your time, guys. Jersey is a great piece of work, I must say.
Sincerely,
Frank
From: Paul Sandoz [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Monday, January 05, 2009 9:52 AM
To: dev_at_jersey.dev.java.net
Subject: Re: [Jersey] Combining Jersey and non-Jersey on one webapp
On Jan 5, 2009, at 3:37 PM, Edelson, Justin wrote:
Paul-
You might want to take a look (if you haven't already) at RESTEasy's SpringMVC integration.
Yes, i know about it. It should be possible to do something similar with Jersey but i am not an expert on Spring and it seems such integration does require some good Spring knowledge.
Paul.
Justin
On Jan 5, 2009, at 7:14 AM, "Paul Sandoz" <Paul.Sandoz_at_Sun.COM<mailto:Paul.Sandoz_at_Sun.COM>> 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?
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<
http://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