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 Thu, 24 Feb 2005 22:25:05 GMT
In all cases the applications run as separate standalone applications (3 
applications) and as separate portlets.

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 

 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.
>> 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.
> From you description alone of this problem (including your previous 
> messages
> 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: 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