Comment #13 on issue 372 by [email protected]: GuiceFilter breaks dispatching to jsp if jasper is being used to compile the jsp
http://code.google.com/p/google-guice/issues/detail?id=372
re#12: I think that's a different issue from the one discussed in the other comments on this bugreport.
Tomcat definitely isn't aware of the mappings define via serve(x).with(y). The whole design is that when the original request comes in, the servlet container will not find a matching servlet (because there is no matching entry in web.xml), so will select the "default servlet" as the target. However it will run the Guice filter first, as that is mapped to "/*". And the guice filter then arranges for the request to be sent to the configured servlet instead of passing it to the (default) servlet that the web container chose.
I would have thought that forwarding from one Guice-configured servlet to another would be supported (eg by creating a custom RequestDispatcher), but it isn't really necessary for most users.
Forwarding from a guice-configured servlet to the container's JSP or static-resource servlet *is* critical, and this is the issue discussed in this bugreport. Note that comment#11 is about using a wildcard-suffix (eg "/admin/*"). The existing code works fine with wildcard-prefixes (eg "*.do"), because UriPatternType.extract returns null in this case, causing ServletDefinition$2.getServletPath() to return the (correct) path from the parent class.
-- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
