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.
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.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Mike Douglass [EMAIL PROTECTED] Senior Systems Programmer Communication & Collaboration Technologies 518 276 6780(voice) 2809 (fax) Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
