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 21:51:51 GMT
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


Mime
View raw message