Mailing-List: contact beehive-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Users" <beehive-user@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42A7169D.2050005@bea.com>
Date: Wed, 08 Jun 2005 10:02:37 -0600
From: Carlin Rogers <crogers@bea.com>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: Beehive Users <beehive-user@incubator.apache.org>
Subject: Re: Problem with "request_uri" attribute
References: 
 <1CB7AC2CE0BECA40875C256CA908B919013A74A4@cacexc06.americas.cpqcorp.net>
 <42A68088.2070808@bea.com>
In-Reply-To: <42A68088.2070808@bea.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Just wanted to follow up and let folks know that I've
logged a Tomcat bug. Please see...
http://issues.apache.org/bugzilla/show_bug.cgi?id=35270
if you're interested.

Thanks,
Carlin

Carlin Rogers wrote:

> Hey Brian,
> 
> Thanks for the detail and the simple reproduction
> information. This really helps out when digging
> into the code.
> 
> It appears that this has something to do with how the
> container manages the request in the RequestDispatcher,
> and may be a problem specific to Tomcat.
> 
> I noticed different behavior between Tomcat and Weblogic.
> With a NetUI deployment on WebLogic, your test below works
> correctly. The page displays /netui-blank/begin.do for the
> "javax.servlet.forward.request_uri" request attribute.
> And going directly to the Controller, the page displays
> /netui-blank/Controller.jpf for this attribute, as
> expected.
> 
> Stepping through the Tomcat source in the debugger, it
> appears that the request's requestURI field gets stomped
> on in the forward method of the RequestDispatcher
> (ApplicationDispatcher). I'm not sure Tomcat is handling
> a ServletRequestWrapper correctly.
> 
> I think the servlet spec says that users may wrap the
> request/response objects with their own implementation.
> This is what we do in NetUI Page Flow.
> 
> Tomcat's ApplicationDispatcher gets the request from
> the outer request (the ServletRequestWrapper), trying to
> keep track of the previous wrapper and current wrapper
> (or request) as it loops through to get the real request.
> With a single wrapper, the value of "previous" is the
> same as the original outer request. Then Tomcat calls...
> 
> ((ServletRequestWrapper) previous).setRequest(wrapper);
> 
> which is the same as calling setRequest(wrapper) on the
> incoming request. Tomcat does not get and save the value
> of the original request URI. It calls setRequestURI(path)
> on the wrapper, effectively changing the request URI of the
> original incoming request to the path of the forward.
> 
> Then Tomcat sets the javax.servlet.forward.request_uri
> attribute by calling getRequestURI() from the original
> request... but that just got modified. Implying the
> javax.servlet.forward.request_uri attribute is going to
> get the value of the path for the forward.
> 
> You can test this on Tomcat by making a simple change to
> your test JSP that does the forward, forward.jsp. Use
> a HttpServletRequestWrapper in the JSP for the forward.
> So, forward.jsp would now contain...
> 
> <%
>   HttpServletRequestWrapper wrapper = new
>       HttpServletRequestWrapper(request);
>   javax.servlet.RequestDispatcher rd =
>       wrapper.getRequestDispatcher("/index.jsp");
>   rd.forward(wrapper, response);
> %>
> 
> ...and "/netui-blank/index.jsp", the forward path
> used by the RequestDispatcher, is displayed.
> 
> Bummer. I guess the next step is to see if this is an
> known issue or not in Tomcat or if this is expected
> behavior.
> 
> Sorry the news isn't better. Hope it helps.
> Carlin
> 
> DeHamer, Brian wrote:
> 
>> Never received a respone to my initial question -- reposting:
>>
>> I have a custom tag that, among other things, needs to read the value of
>> the "javax.servlet.forward.request_uri" request attribute.  Under plain
>> ol' Struts I found that this attribute would always contain the URI of
>> the original request from the client, even after multiple forwards (as
>> per servlet spec SRV.8.4.2). 
>> Now that I'm trying to use my tag in conjunction with Beehive JPF
>> (1.0m1) I'm finding that this attribute no longer contains the URI for
>> the original request, but instead contains the URI for the forwarded
>> request.  I tried to find the most simple use case that reproduces the
>> problem so I started with a fresh instance of the netui-blank webapp and
>> simply added the following line to the provided index.jsp page:
>>
>> <%= request.getAttribute("javax.servlet.forward.request_uri") %>
>>
>> When invoking /begin.do from my browser I get forwarded to index.jsp and
>> I expect that the page output will display "/netui-blank/begin.do", but
>> instead what I see is "/netui-blank/index.jsp".
>>
>> Just as a quick sanity check, I created another JSP called forward.jsp
>> that contains only the following:
>>
>> <%
>>   javax.servlet.RequestDispatcher rd =
>> request.getRequestDispatcher("/index.jsp");
>>   rd.forward(request, response);
>> %>
>>
>> When I access forward.jsp directly (no JPF code involved) I still get
>> forwarded to index.jsp, but this time I see the output I would expect:
>> "/netui-blank/forward.jsp".
>>
>> It would appear that this attribute isn't being set properly as a result
>> of being processed by the PageFlowActionServlet.  Any ideas?  Thanks.
>>
>> Brian DeHamer
>>
> 
>