"David H. DeWolf" <[EMAIL PROTECTED]> 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
