Christopher Piggott wrote:
> I fixed that. Again, the web.xml had a problem. When you define a
> <filter> you apparently have to also define a <filter-mapping> that
> matches it. Looking at the example in
> https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/contribs/jersey-guice/com/sun/jersey/guice/spi/container/servlet/package-summary.html
> I thought that if you didn't declare a filter-mapping it would default
> to mapping to everything. Apparently not. (I should have known this
> - I had the same problem the first time I ever declared a <servlet>
> without a <servlet-mapping>)
>
> Apologies for what turned out to be a problem with my tomcat
> configuration, really having nothing to do with jersey.
>
>
> So ... I have a more-or-less complete example now, using guice, tomcat
> 6.0.18, and jersey 1.1.0-ea. If anybody needs any snippets on how I
> made this work please let me know. It is all a lot of fun once you
> get it going.
It's more or less what I wound up with as well.
This bit's interesting:
serve("/*").with(GuiceContainer.class);
it gives me an error because GuiceContainer does not extends HttpServlet
so I end up only using filter("/*").through. What dependencies are you
using?
I ran into a JSP rendering problem with Guice; apparently it's a known
bug with the way things are forwarded. The workaround for me is not to
put the Guice filter into web.xml for injection, instead I have jersey
resources inject their fields manually (which kind of sucks
unfortunately). That or ensure Guice's filter is not in the same
url-pattern scope as the the JSPs.
Bill