portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: portal-struts bridge problems
Date Thu, 24 Feb 2005 22:52:20 GMT


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.

> 
> 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?
> 
> 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.
The request dispatchers used in the Struts Bridge don't have any custom code
related to buffering so its behavior in this respect is still pure Tomcat based.

> 
> 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.

> 
> 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
>>
>>
> 


---------------------------------------------------------------------
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