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.
The result is that the filter sees nothing if the total output is < 8k or 1 or more 8k chunks if it is >8k. It does not see the partially filled buffer.
I suspect that the struts request dispatcher does a flush at some point, tomcat does a flush after an include - the comment being somethig to the effect that you cannot assume the included servlet terminated with a flush.
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?
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?
The filter solution I tried which I thought didn't work at all does seem to work better than I thought (after fixing a bug). However, thsi only works if the HttpSession is always obtained via the request. I have a feeling there are other ways to get hold of it.
Ate Douma wrote:
Mike Douglass wrote:
I've been working to turn some struts application into portlets using the jetspeed2 portal-struts bridge.From you description alone of this problem (including your previous messages
I've run into a couple of problems, one of which I managed to work around, the other is more difficult.
First the applications are a suite of struts applications, the uw calendar in fact,
an admin tool - just struts and jsp
two user clients, identical except one is authenticated for personal events, one unauthenticated for public events.
The user clients use the struts framework and jsp to generate xml and use an xslt filter to generate ical, html whatever - but normally html.
All work standalone.
Problem 1.
In the bridge the admin client eventually worked. The user clients would not work until I appended
<% pageContext.getOut().flush(); %>
to the jsp. The behaviour I was seeing was either no data or 8k of truncated data - 8k being the default buffer size for the page context.
It's a relatively trivial problem but I guess the servlet container flushes before returning to the filter.
After that each application works by itself in the portal.
about it) I still don't understand exactly what happens and if it is portals
struts-bridge related or not. My current impression is that isn't and probably
more related to how the portal aggregation works but I could be wrong.
Problem 2.
More difficult. Because these use a common framework, there are a number of session attributes with the same name. The attributes for each application collide.
My first question is how you these apps are deployed and used in a non-portal
environment as you say they work standalone.
I think you have deployed these as one portlet application (hence the shared
session).
In a standalone environment are these deployed as one web application too?
If that is the case, I would expect you will be hit by session attribute collision
just as well when a user accesses these (sub)applications from the same browser
window (and thus using the same session too).
If that is not the case (you deploy them as separate web applications) then you
should do the same in the portal. Different portlet applications won't share their
session.
At least, if you are not running under Tomcat 4 which has a bug (several actually)
with its session management. Its the most important reason I won't use Tomcat 4 anymore
(for Portals).
I personally think we (Jetspeed-2 team) should kick Tomcat 4 support all together but
thats another issue.
I tried various work rounds but none are succesful for one reason or another.
I assume that the attributes sould really be stored in the PORTLET_SCOPE (PLT.15.3) but I'm not sure how to make that work in the bridge.
That should fix you problem and its rather easy to do, but requires dependency on
the Portlet Api. If you intend to use the same codebase for standalone and portlet
deployment make sure to encapsulate it properly.
From within a servlet/jsp, the current portlet RenderRequest is available as
(HttpServlet)Request attribute "javax.portlet.request". See PLT.16.3.2.
Through the RenderRequest you can access and store attributes in PortletSession.PORTLET_SCOPE.
Anyway, again this isn't really a portal-struts bridge problem but related to
Portlet Application deployment and using servlets within a Portlet in general.
I did try adding a filter which wrapped the HttpSession and prefixed the attribute names. This failed very rapidly as the TagUtil class uses the pageContext to locate attributes and I suspect that is set up before the filter so it was looking for the unprefixed name.
Is there any way I can work round this?
--------------------------------------------------------------------- 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]
