Hi,
Jersey declares a ServletContainerInitializer implementation that
handles any subclass of Application annotated with @ApplicationPath
and will deploy Jersey using the "normal" Jersey servlet.
For Guice i recommend you do not use the @ApplicationPath. Especially
since for Guice deployment the developer declares a subclass of
GuiceServletContextListener and then defines the URL pattern in the
subclass of ServletModule.
Note that Guice JavaDoc states:
"It is possible to intermix Guice and non-Guice registration of
classes by additionally using the normal Jersey-based registration
mechanisms in the servlet context listener implementation."
http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
In general the issue is there are now two types of deployment and when
mixing the two sometimes it is not clear what is going on. Furthermore
it is not clear in some cases to detect erroneous from correct
deployment, for example if the filter URL pattern is the same as the
servlet URL pattern.
To better understand your issue i would need to look at your code as i
want to know if you bound your resource classes using Guice or you
wanted to use the behavior that is documented at:
"Sometimes it is convenient for developers not to explicitly bind a
resource or provider, let Guice instantiate, and let Jersey manage the
life-cycle."
http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
I suspected you wanted the latter behavior, which is actually
orthogonal to the use of @ApplicationPath.
Paul.
P.S. Note that the value of the @ApplicationPath is not a URL pattern
but just a URL path:
http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/ApplicationPath.html
On Jan 15, 2011, at 8:33 AM, Gili wrote:
>
> It turns out that the existence of a DefaultResourceConfig subclass
> was
> overriding Guice's servlet filter defined in web.xml.
>
> @ApplicationPath("/*")
> public class ApplicationConfig extends DefaultResourceConfig
> {
> }
>
> Once I removed this class Guice injection worked as expected. The next
> question was how to combine GuiceServletContextListener and
> DefaultResourceConfig. Maybe I'm particularly slow after working at
> this for
> hours but it really wasn't obvious how to accomplish this. When I use
> DefaultResourceConfig, Jersey automatically registers a whole bunch of
> Mappers and Providers for me:
>
> INFO: Instantiated the Application class
> com.foo.health.server.ApplicationConfig. The following root resource
> and
> provider classes are registered: [class
> org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider, class
> org.codehaus.jackson.jaxrs.JsonParseExceptionMapper, class
> com.foo.health.server.DoctorsResource, class
> org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper, class
> org.codehaus.jackson.jaxrs.JacksonJsonProvider]
>
> If you follow the documentation for GuiceServletContextListener you
> won't
> end up with any of these important mappers/providers. Anyway, a few
> hours
> later I figured it out.
>
> Paul, can you please update
> http://jersey.java.net/nonav/apidocs/latest/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
> to mention the following important line of code?
>
> params.put(ServletContainer.RESOURCE_CONFIG_CLASS,
> ClasspathResourceConfig.class.getName());
>
> Hopefully it'll save others some time in the future :)
>
> Thank you,
> Gili
> --
> View this message in context: http://jersey.576304.n2.nabble.com/jersey-guice-Missing-dependency-for-constructor-tp5920703p5924265.html
> Sent from the Jersey mailing list archive at Nabble.com.