On 5/26/10 6:36 PM, Eric Dalquist wrote:
I was just going to ask about the TCK, is it just linked of the JSR page?Some additional help would be great. I did a lot of tracing through HttpServletPortletRequestWrapper and it appeared to be doing what is was intended to do and I didn't see a way for the driver or portal to really influence the value being returned by getContextPath() but I'll be honest and say that I didn't really understand everything that was going on in there.Thanks for catching that other fix. I had a local pluto install running but apparently managed to avoid triggering any eventing.-Eric On 5/26/10 4:27 PM, Ate Douma wrote: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
smime.p7s
Description: S/MIME Cryptographic Signature
