portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Meier <peter.me...@tec.govt.nz>
Subject Re: portal-struts bridge problems
Date Fri, 25 Feb 2005 04:47:18 GMT

Mike Douglass wrote:

>
>
> 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 
>>> APPLICATION_SCOPE and PORTLET_SCOPE.
>>>
>>>  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.

I observed the same problem.- But, I was fortunate being able to change 
the attribute names as a work around in the meantime. -

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

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


Mime
View raw message