PLUTO-124 and HTTP redirection

[Pawel Kozlowski <pa...@gmail.com>]

Hi,

I'm working at the simple portal framework based on Pluto (1.1-beta
currently). Unfortunately, I've run into issue PLUTO-124.

So, I've got 2 questions:

1)	Is there any chance that this issue would be fixed anytime soon? Of
course I can help with this one.

2)	I wonder if, while fixing PLUTO-124, it would be possible to have a
pluggable strategy fragment sending a redirection after processing an
action request (class PortletContainerImpl, method doAction)?
Currently, this implementation will always send a HTTP redirect and it
is impossible to create a portal implementation that would process an
action and a render request in one HTTP request. As fare I know, this
model of portal request processing is not forbidden by JSR-168?

So, basically, I would like you to tell me if you think it is possible
to address the issues described. If you could provide me with some
starting points / directions I could play with the code a little bit.

Brgds,
Pawel Kozlowski

Re: PLUTO-124 and HTTP redirection

[Eric Dalquist <er...@doit.wisc.edu>]

The bit where action IDs would be needed is to make sure hitting refresh 
after clicking an action URL just triggered a render. The spec restricts 
actions to be executed exactly once. You would need to have some sort of 
identifier used to make sure if after clicking an action URL the user 
hit refresh the action was not performed a second time and just a render 
was executed. That is really the core of the issue. There can be other 
issues with WindowStates and PortletModes but that depends more on how 
your portal deals with those aspects and how they are changed during an 
action.

-Eric

Pawel Kozlowski wrote:
>
>
> Stefan Hepper <st...@apache.org> wrote on 15/02/2007 09:34:22:
>
> > Right, you would need some kind of action ID in each action URL and
> > check if that action was already executed or not.
> >
> > Stefan
> >
> > Eric Dalquist wrote:
> > > My 2 cents on this issue:
> > >
> > > At one point in the past uPortal 2.4 had overridden the redirect
> > > behavior using pluto 1.0 We ditched this after running into numerous
> > > spec compliance issues that were much easier to resolve by using
> > > redirects. Much of it had to do with ensuring actions only occurred
> > > once, making the back & forward buttons functional, dealing with an
> > > actions ability to change the state/mode send redirects and such.
>
>
> Hi Stefan, Eric,
>
> Unfortunately, I've got a "valid use case": I'm planning to use Pluto 
> + Spring Web Flow + existing MVC controllers. The problem is that 
> shoes controllers were written before the redirect-after-post 
> movement. Those controllers are putting their results in a HTTP 
> request and rewriting those controllers is not an option….
>
> But, going back to your comment regarding action ids – I'm afraid I 
> can't see the problem… Could you elaborate more?
>
> I was envisioning an implementation in which the portal framework is 
> reading a configuration of a page (all the portlet / portlet windows 
> on the given page) and:
>
> if this is an action request (action parameter = true and valid 
> portlet window id in the URL), execute an action request against for 
> the specified portlet window id
> execute render request against all the portlets on the page
>
> In case of the render request coming to the portal I would simply 
> execute render request against all the portlets on the page
>
>
> So, for me, for each HTTP request that would be an exactly one action 
> request and several render requests. So, that is why I'm puzzled by 
> action ids in the urls… Sorry if I'm asking obvious questions, but my 
> experience with porltlet containers / Pluto is next to nothing, 
> compared to yours… Would be really grateful for more explanations…
>
> Brgds,
> Pawel 

Re: PLUTO-124 and HTTP redirection

[Pawel Kozlowski <pk...@amadeus.com>]

Stefan Hepper <st...@apache.org> wrote on 15/02/2007 09:34:22:

> Right, you would need some kind of action ID in each action URL and 
> check if that action was already executed or not.
> 
> Stefan
> 
> Eric Dalquist wrote:
> > My 2 cents on this issue:
> >
> > At one point in the past uPortal 2.4 had overridden the redirect 
> > behavior using pluto 1.0 We ditched this after running into numerous 
> > spec compliance issues that were much easier to resolve by using 
> > redirects. Much of it had to do with ensuring actions only occurred 
> > once, making the back & forward buttons functional, dealing with an 
> > actions ability to change the state/mode send redirects and such.


Hi Stefan, Eric,

Unfortunately, I've got a "valid use case": I'm planning to use Pluto + 
Spring Web Flow + existing MVC controllers. The problem is that shoes 
controllers were written before the redirect-after-post movement. Those 
controllers are putting their results in a HTTP request and rewriting 
those controllers is not an option?.

But, going back to your comment regarding action ids ? I'm afraid I can't 
see the problem? Could you elaborate more? 

I was envisioning an implementation in which the portal framework is 
reading a configuration of a page (all the portlet / portlet windows on 
the given page) and:

if this is an action request (action parameter = true and valid portlet 
window id in the URL), execute an action request against for the specified 
portlet window id
execute render request against all the portlets on the page

In case of the render request coming to the portal I would simply execute 
render request against all the portlets on the page


So, for me, for each HTTP request that would be an exactly one action 
request and several render requests. So, that is why I'm puzzled by action 
ids in the urls? Sorry if I'm asking obvious questions, but my experience 
with porltlet containers / Pluto is next to nothing, compared to yours? 
Would be really grateful for more explanations?

Brgds,
Pawel

Re: PLUTO-124 and HTTP redirection

[Stefan Hepper <st...@apache.org>]

Right, you would need some kind of action ID in each action URL and 
check if that action was already executed or not.

Stefan

Eric Dalquist wrote:
> My 2 cents on this issue:
>
> At one point in the past uPortal 2.4 had overridden the redirect 
> behavior using pluto 1.0 We ditched this after running into numerous 
> spec compliance issues that were much easier to resolve by using 
> redirects. Much of it had to do with ensuring actions only occurred 
> once, making the back & forward buttons functional, dealing with an 
> actions ability to change the state/mode send redirects and such.
>
> I'm not saying you don't have a good use case for not doing redirects 
> between action and render but unless you have a reason beyond not 
> wanting to do the 302 I would say it is much more work than it is worth.
>
> -Eric
>
> David H. DeWolf wrote:
>>
>>
>> Pawel Kozlowski wrote:
>>> Hi,
>>>
>>> I'm working at the simple portal framework based on Pluto (1.1-beta
>>> currently). Unfortunately, I've run into issue PLUTO-124.
>>>
>>> So, I've got 2 questions:
>>>
>>> 1)    Is there any chance that this issue would be fixed anytime 
>>> soon? Of
>>> course I can help with this one.
>>
>> The best bet for getting this enhancement asap would be to submit a 
>> patch.  Otherwise, you're at the mercy of the committers to feel as 
>> though it's important enough :)
>>
>> I still don't really understand why this is needed.  Are you 
>> converting all of the post data into render parameters and the render 
>> parameter string blows the url buffer?  Is that the issue?
>>
>>>
>>> 2)    I wonder if, while fixing PLUTO-124, it would be possible to 
>>> have a
>>> pluggable strategy fragment sending a redirection after processing an
>>> action request (class PortletContainerImpl, method doAction)?
>>> Currently, this implementation will always send a HTTP redirect and it
>>> is impossible to create a portal implementation that would process an
>>> action and a render request in one HTTP request. As fare I know, this
>>> model of portal request processing is not forbidden by JSR-168?
>>
>> No, it's not forbidden BUT it's also not impossible with the current 
>> implementation.  Remember that the request/response provided to the 
>> container can be wrapped by the webapp/portal embedding the container 
>> to intercept any of the method calls.
>>
>> Additionally the url provider could store request parameter state in 
>> the session as opposed to parameters.  Take a look at the sakai 
>> charon velocity branch as an example if you're looking for an impl 
>> that will do that.
>>
>>>
>>> So, basically, I would like you to tell me if you think it is possible
>>> to address the issues described. If you could provide me with some
>>> starting points / directions I could play with the code a little bit.
>>
>> It's possible, but since there are work arounds, it's not on my 
>> "high" priority list.  That said, if you submit a patch for an 
>> enhancement, I'll at least take a look at it and commit if I think it 
>> makes sense. Feel free to ping ideas off the list before you code it 
>> up and I'll do my best to comment.
>>
>> David
>>>
>>> Brgds,
>>> Pawel Kozlowski
>>>

Re: PLUTO-124 and HTTP redirection

[Eric Dalquist <er...@doit.wisc.edu>]

My 2 cents on this issue:

At one point in the past uPortal 2.4 had overridden the redirect 
behavior using pluto 1.0 We ditched this after running into numerous 
spec compliance issues that were much easier to resolve by using 
redirects. Much of it had to do with ensuring actions only occurred 
once, making the back & forward buttons functional, dealing with an 
actions ability to change the state/mode send redirects and such.

I'm not saying you don't have a good use case for not doing redirects 
between action and render but unless you have a reason beyond not 
wanting to do the 302 I would say it is much more work than it is worth.

-Eric

David H. DeWolf wrote:
>
>
> Pawel Kozlowski wrote:
>> Hi,
>>
>> I'm working at the simple portal framework based on Pluto (1.1-beta
>> currently). Unfortunately, I've run into issue PLUTO-124.
>>
>> So, I've got 2 questions:
>>
>> 1)    Is there any chance that this issue would be fixed anytime 
>> soon? Of
>> course I can help with this one.
>
> The best bet for getting this enhancement asap would be to submit a 
> patch.  Otherwise, you're at the mercy of the committers to feel as 
> though it's important enough :)
>
> I still don't really understand why this is needed.  Are you 
> converting all of the post data into render parameters and the render 
> parameter string blows the url buffer?  Is that the issue?
>
>>
>> 2)    I wonder if, while fixing PLUTO-124, it would be possible to 
>> have a
>> pluggable strategy fragment sending a redirection after processing an
>> action request (class PortletContainerImpl, method doAction)?
>> Currently, this implementation will always send a HTTP redirect and it
>> is impossible to create a portal implementation that would process an
>> action and a render request in one HTTP request. As fare I know, this
>> model of portal request processing is not forbidden by JSR-168?
>
> No, it's not forbidden BUT it's also not impossible with the current 
> implementation.  Remember that the request/response provided to the 
> container can be wrapped by the webapp/portal embedding the container 
> to intercept any of the method calls.
>
> Additionally the url provider could store request parameter state in 
> the session as opposed to parameters.  Take a look at the sakai charon 
> velocity branch as an example if you're looking for an impl that will 
> do that.
>
>>
>> So, basically, I would like you to tell me if you think it is possible
>> to address the issues described. If you could provide me with some
>> starting points / directions I could play with the code a little bit.
>
> It's possible, but since there are work arounds, it's not on my "high" 
> priority list.  That said, if you submit a patch for an enhancement, 
> I'll at least take a look at it and commit if I think it makes sense. 
> Feel free to ping ideas off the list before you code it up and I'll do 
> my best to comment.
>
> David
>>
>> Brgds,
>> Pawel Kozlowski
>>

Re: PLUTO-124 and HTTP redirection

[Pawel Kozlowski <pk...@amadeus.com>]

"David H. DeWolf" <dd...@apache.org> wrote on 13/02/2007 14:55:50:

> > I'm working at the simple portal framework based on Pluto (1.1-beta
> > currently). Unfortunately, I've run into issue PLUTO-124.

> 
> I still don't really understand why this is needed.  Are you converting 
> all of the post data into render parameters and the render parameter 
> string blows the url buffer?  Is that the issue?


No, actually I saw this issue when using Spring web Flow in a portlet 
environment. The problems comes from the fact that Spring PortletMVC (this 
one is driving SWF execution) is putting very loooong strings as render 
parameters. It is happening when there is an exception during an action 
request. Spring PortletMVC will put ex.toString() as a render parameter.

So, there are 2 issues here:

Awful URL in case of the Spring PortletMVC exception. This is rather for 
the Spring team, I'll contact them.

Issue (1) made me wonder what would happen in case of the long list of 
render parameters, I did a little googling and stumbled upon PLUTO-124. 
So, I don't have a "real" scenario when this is screwing sth up.

So, the PLUTO-124 just makes me a little bit suspicious? Obviously, 
playing with an URL provider is a solution.



> > 2)    I wonder if, while fixing PLUTO-124, it would be possible to 
have a
> > pluggable strategy fragment sending a redirection after processing an
> > action request (class PortletContainerImpl, method doAction)?
> > Currently, this implementation will always send a HTTP redirect and it
> > is impossible to create a portal implementation that would process an
> > action and a render request in one HTTP request. As fare I know, this
> > model of portal request processing is not forbidden by JSR-168?
> 
> No, it's not forbidden BUT it's also not impossible with the current 
> implementation.  Remember that the request/response provided to the 
> container can be wrapped by the webapp/portal embedding the container to 

> intercept any of the method calls.


I had a closer look at the code, and yes, wrapping HttpServletResponse 
sounds like reasonable, option, but? what about valid redirections, coming 
from a portlet? The problem is that I won't be able to distinguish if the 
redirection originates from actionResponse.getRedirectLocation() or from 
Pluto container. OK, it would be possible to compare string 
representations of the redirection URL, but it sounds like a fishy option?

Am I missing sth obvious here?


Brgds,
Pawel

Re: PLUTO-124 and HTTP redirection

["David H. DeWolf" <dd...@apache.org>]

Pawel Kozlowski wrote:
> Hi,
> 
> I'm working at the simple portal framework based on Pluto (1.1-beta
> currently). Unfortunately, I've run into issue PLUTO-124.
> 
> So, I've got 2 questions:
> 
> 1)    Is there any chance that this issue would be fixed anytime soon? Of
> course I can help with this one.

The best bet for getting this enhancement asap would be to submit a 
patch.  Otherwise, you're at the mercy of the committers to feel as 
though it's important enough :)

I still don't really understand why this is needed.  Are you converting 
all of the post data into render parameters and the render parameter 
string blows the url buffer?  Is that the issue?

> 
> 2)    I wonder if, while fixing PLUTO-124, it would be possible to have a
> pluggable strategy fragment sending a redirection after processing an
> action request (class PortletContainerImpl, method doAction)?
> Currently, this implementation will always send a HTTP redirect and it
> is impossible to create a portal implementation that would process an
> action and a render request in one HTTP request. As fare I know, this
> model of portal request processing is not forbidden by JSR-168?

No, it's not forbidden BUT it's also not impossible with the current 
implementation.  Remember that the request/response provided to the 
container can be wrapped by the webapp/portal embedding the container to 
intercept any of the method calls.

Additionally the url provider could store request parameter state in the 
session as opposed to parameters.  Take a look at the sakai charon 
velocity branch as an example if you're looking for an impl that will do 
that.

> 
> So, basically, I would like you to tell me if you think it is possible
> to address the issues described. If you could provide me with some
> starting points / directions I could play with the code a little bit.

It's possible, but since there are work arounds, it's not on my "high" 
priority list.  That said, if you submit a patch for an enhancement, 
I'll at least take a look at it and commit if I think it makes sense. 
Feel free to ping ideas off the list before you code it up and I'll do 
my best to comment.

David
> 
> Brgds,
> Pawel Kozlowski
>