On Jul 4, 2009, at 12:41 PM, Bill de hOra wrote:
> 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?
>
You need to use Jersey version 1.1.0-ea or greater for all Jersey-
based jars.
In previous versions of Jersey i re-factored the Jersey
ServletContainer (from which GuiceContainer extends) to not extend
from HttpServlet, then i factored it back in because of issues with
Guice integration,
> 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.
>
:-(
Paul.