Well, as a workaround, I've resorted to using this when I need to do a
forward:
protected static ServletRequest getUnderlyingRequest
( HttpServletRequest request )
{
ServletRequest innerRequest = request;
while ( innerRequest instanceof HttpServletRequestWrapper )
{
innerRequest = ( ( HttpServletRequestWrapper )
innerRequest ).getRequest();
}
return innerRequest;
}
It's pure hack but I can live with it until it gets fixed in Guice.
And I believe the WEB-INF jsp trick is only valid for recent versions
of the spec, I only learned of this in the past couple of years myself
but it's great for keeping your jsps private.
On May 5, 8:09 am, Alen Vrecko <alen_vre...@yahoo.com> wrote:
> > Hey, thanks for the reply.
>
> Hi. You to. I'll learn from this.
>
> > I am just using the snapshot build.
>
> I don't think there is any difference with regards to servlets.
>
> > From my understanding, if I am using the dispatcher from
> > ServletRequest, forwards and includes will be relative to the servlet
> > path unless preceded by a slash. In that case, it's relative to
> > context root, i.e. WebContent. At least this is how it works in
> > Tomcat and WebSphere.
>
> You're right. In the servlet spec I found this part a bit confusing it
> only explicitly mentions the relative paths. Thanks for clarifying
> this.
>
> > I tried using the RequestDispatcher from ServletContext without Guice
> > (straight web.xml mapping) on Tomcat and it looks like it actually
> > wants all paths to start with a slash, it too serves relative to
> > context root.
>
> On the other hand this is explicitly mentioned in the spec.
> RequestDispatcher for ServletContext must start with a slash. I
> thought Context and Request dispatcher are exclusive one is absolute
> the other relative. But the latter is only complementary. Great.
>
>
>
> > WEB-INF is special in that it can't be access directly from the client
> > side but you're allowed to access it internally via a request
> > dispatcher.
>
> Right. I've always thought there is somebody with a shotgun protecting
> WEB-INF. I was wrong;)
>
> > I experimented with getServletContext().getRequestDispatcher() with
> > the Guice servlet adapter and it too doesn't work with forwards but
> > it's fine with include.
> > So the request dispatcher doesn't seem to
> > make a difference and stepping through the debug showed it was the
> > same problem with the servlet path reported by the server request
> > wrapper.
>
> Got it! Squash! Like there is a saying Premature Optimization is the
> root of all evil or something like that.
>
> What happens is that the Wrapper caches the paths but when you forward
> the paths in the original request are changed but the wrapper returns
> the old cached path!
>
> Quick fix is just to get rid of the Memoizer in ServletDefinition
> lines 203+. Hope that helps.
>
> Will take a closer look at this wrapper soon and maybe make a patch or
> something.
>
> > I don't think that's the case. When I tried /test in my browser, it
> > did make a request for /test on the servlet side, sans final slash.
>
> Never mind. What was I thinking? Nothing! Today it works as expected.
> Must been some Heisenbug in the browser or something.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com
To unsubscribe from this group, send email to
google-guice+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
