[ 
https://issues.apache.org/jira/browse/PLUTO-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647084#action_12647084
 ] 

Michael Freedman commented on PLUTO-478:
----------------------------------------

As the Pluto (internal) Request/response objects are already HTTServlet... 
wrappers and these already have special code in them to flag when they are 
called in the incldued/forwarded state -- I would expect the implementation to 
be something along the lines of:

These internal request/response objects would remember the origin dispatched 
objects (if these are wrapped objects).  And then for any method that the spec 
says the portlet is supposed to provide the answer/function from doing the 
equivalent portlet behavior you would have the internal request/response object 
call the wrapped object to do the work.  It also probably needs to set an 
internal flag so that if it gets delegated back to it can detect it should do 
the work vs execute the wrapper again. 

> Portlet Dispatching loses wrappers
> ----------------------------------
>
>                 Key: PLUTO-478
>                 URL: https://issues.apache.org/jira/browse/PLUTO-478
>             Project: Pluto
>          Issue Type: Bug
>          Components: portlet container
>    Affects Versions: 2.0.0
>            Reporter: Michael Freedman
>             Fix For: 2.0.0
>
>
> When you dispatch using a wrapped request/response object, pluto doesn't 
> preserve the wrapping when it executes the dispatch.  I.e. it upwraps the 
> request/response and dispatches on that.  This prevents portlets from 
> filtering request/responses to/from dispatched/servlet entities.
> It would be nice if we added a TCK test for this case as well.  The spec is 
> clear that one can use a wrapped request/response to dispatch to.  Though it 
> doesn't specifically state that this must be preserved, it not only is the 
> reasonable interpreation/expectation but is what clients will be counting on. 
>  Hence for the sake of interoperability, having a TCK test will catch this 
> problem early.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to