Hi Eric,
As you probably already noticed I had to rollback you change for this issue as it caused the Portlet 2.0 TCK to fail on two tests (the
AccessToPathServeResourceForwardTest and MultipleForwardsServeResourceForwardTest).
Sorry for responding so late after you question but I've been too occupied the
last few weeks with clients to have any spare cycles.
I've already commented in detail on PLUTO-590 why fixing this issue requires very careful investigation and testing to ensure we don't break
the portlet spec semantics.
I'll try to help out and investigate myself shortly, for that reason I
reassigned the issue to myself.
If you want to take the issue back though, don't hesitate to do so: my time really is very limited at the moment and I can only work on this
in my own spare time right now.
I also like to suggest to download and run the 2.0 TCK yourself too: it really is very helpful with validating core/container changes as
AFAIK you're planning to do for the current 2.1.0-SNAPSHOT trunk. If you need any help setting that up, just let me know. By
default/out-of-the-box the 2.0 TCK is setup for testing with Pluto so there is not much configuration needed to get it running properly.
(btw: the other fix I just applied for PLUTO-593 was also detected by the TCK:
without it there were an additional 67 test failures ;) )
Regards,
Ate
On 05/21/2010 07:29 PM, Eric Dalquist wrote:
Actually reading further I'm not sure why
HttpServletPortletRequestWrapper.getContextPath() isn't simply
delegating to PortletRequest.getContextPath().
I'm going to make that change for fixing PLUTO-590, please let me know
if the old impl was there for a reason.
-Eric
On 5/21/10 11:50 AM, Eric Dalquist wrote:
I'm trying to figure out whats going on with
https://issues.apache.org/jira/browse/PLUTO-590
What we see is that when a portlet uses a PortletRequestDispatcher the
target of the dispatcher sees HttpServletRequest.getContextPath()
returning the context path of the portal instead of the portlet.
Digging into HttpServletPortletRequestWrapper the code is returning
"pathMethodValues.contextPath" which appears to have information about
the original request to the portal. The correct context path is in the
currPathAttributeValues Map but not used. My initial reaction is to
switch the data source for this method but I wanted to get some
feedback on the implementation of this class, its fairly complex and I
want to make sure I'm understanding whats going on correctly.
-Eric
