On 05/27/2010 02:12 AM, Eric Dalquist wrote:
I'm getting a 'Connection Reset' error when trying to get the TCK from:
http://hnsp.inf-bb.uni-jena.de/tck/
Hmm, I tried it too with same result.
I'll notify this problem on the 286 EG group list.
For the time being, I will email you the tck directly (portlet-tck070508.zip,
15Mb).
I also will check in a README.TCK in the pluto trunk root explaining how to
setup and run the TCK
(derived from the readme.txt we have in Jetspeed trunk /etc/tck-jsr-286, but
that one is Jetspeed specific).
Regards,
Ate
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
