I read the section of the specification that you referring to and I think that you have it backwards. It doesn't say in the specification that when you do a requestDispatcher.include() that you should change the request.getRequestURI(). What I do see in the spec is that the request attribute of javax.servlet.include.request_uri refers to the page that was included, not the original requestURI. This behavior is already built into the RequestDispatcher.include(). Whats more, when you do the include the RequestDispatcher will overwrite any existing value that is in the request attributes for javax.servlet.include.request_uri and replace it with the path for the page that is included. So even if Struts put the original requestURI in the attributes under this key, it will get overwritten when the Tiles does the include. This is what I saw when I tested as well. Here is the scenario:
1) Browser requests resource home.do 2) home.do executes ForwardAction to tiles definition home.pg 3) Tiles definition home.pg has body.jsp as the template and overview.jsp as a put 4) From page overview.jsp, I get /plfi-struts/WEB-INF/templates/body.jsp as the value for request.getRequestURI() and /plfi-struts/WEB-INF/metrics/home/overview.jsp as the value for request.getAttribute( "javax.servlet.include.request_uri" ) >From what you describe, this should be the original requestURI, which was /home.do I don't think the writers of the servlet specification intended the consumers to change the request.getRequestURI() when ever they do an include. If struts does nothing with respect to changing the requestURI and the javax. attribute, everything will work as the specification says. Just my humble opinion. -james On Tue, 2003-11-11 at 14:27, Craig R. McClanahan wrote: > Quoting James Norman <[EMAIL PROTECTED]>: > > > I'm in the process of porting a web application from the > > Jetspeed/Turbine framework over to struts and I ran into a problem > > someone may be able to help me with. > > > > When I have a Jsp that is included by a tile, the > > httpServletRequest.getRequestURI() returns the location of the Jsp that > > the tiles included, not the resource that the browser requested. As far > > as I can tell, it is the Tiles Controller that is changing this from the > > original set by the container. This is causing some problems in the > > application I have because the requestURI becomes something like > > /WEB-INF/templates/body.jsp, which isn't terribly useful. I have found > > a few emails regarding this in the archives, but no solutions. Is there > > a configuration which will tell the controller not to mess with the > > requestURI? Any insight would be appreciated. > > > > You will see this sort of behavior in any servlet-based application that uses > RequestDispatcher.incude() -- as Tiles does -- to assemble the various > subcomponents of the page together. The servlet API requires that the request > URI (as well as the other path components like the servlet path) be adjusted in > such scenarios to point at the included resource. > > The request URI of the original request is still available to the included > resource, however -- it's stored by the container in a request attribute under > the key "javax.servlet.include.request_uri", along with the other path > components under similarly named keys. See Section 8.3.1 of the Servlet Spec > for details. > > > Thanks, > > James Norman > > > > Craig > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
