portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Douglass <dou...@rpi.edu>
Subject Re: portal-struts bridge problems
Date Fri, 25 Feb 2005 04:35:04 GMT

Ate Douma wrote:

> Mike Douglass wrote:
>> In all cases the applications run as separate standalone applications 
>> (3 applications) and as separate portlets.
> Then you should consider running them as separate portlet *applications*.
> Package them in separate war files with their own portlet.xml and they
> they won't share session state at all.

They already are in separate war files.

>> The first problem shows up because the xslt filter wraps the response 
>> object on the way in and collects the output in a byte buffer.
>> On return it transforms the buffer and writes it to the now unwrapped 
>> response object.
>> As a standalone app, a flush is clearly being carried out before the 
>> filter regains control. In the portal-bridge case no such flush takes 
>> place.
> Can't you flush the wrapped buffer from within the filter itself 
> before it
> transforms the content?

It's not the wrapped buffer that needs flushing but the level writing to 
the wrapped buffer. As it happens I can flush it from the jsp but my 
point is that the behaviour differs from that of a servlet container and 
others may not be in a position to flush the generated output.

>> In the second problem, because the apps have a common framework, they 
>> have a number of session attributes with the same name. They are 
>> being run as separate portlets but, because they are running in the 
>> portal-struts bridge are not aware of the distinction between 
>>  From my reading of the portlet-spec, section PLT.15.3 something is 
>> supposed to prefix PORTAL_SCOPE attributes with 'javax.protlet.p.<ID>?'
>>  From the example given, I think it's saying that the PortletSession 
>> object itself is suppose to do the prefixing - is that correct?
> Yes.
>> If that's so, I believe that a wrapped struts application should have 
>> all it's session attributes stored in the PORTLET_SCOPE because a 
>> struts application typically runs isolated from other applications. 
>> Shouldn't the portal-bridge store them in that scope by default?
> No.
> As I wrote above, Struts applications intended to be run isolated 
> should be
> deployed as separate portlet applications and not merged together in one.
> The default APPLICATION_SCOPE usage (as per the Portlet Specification) is
> to *allow* using different (Struts) portlets/servlets in one portlet 
> application
> with the need to be able to share information using the session.
That's exactly my problem. They are built as completely separate 
portlets, packaged separately but still end up with session attributes 
colliding. The only point of commonality is they they are deployed into 
the same portal.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message