Re: PLUTO 1.1.0-beta2 : Invalidating HTTP Sessions in portlet applications

Alonso,
On second thought, your problem may not be related to PLUTO-234. Please 
comment.
/Craig


[email protected] wrote on 12/05/2006 09:18:53 AM:

> 
> Hi Alonso, 
> 
> The Session Timeout Test of the testsuite fails using the Pluto 1.1-
> beta2 binary build, and there is a Jira issue on this (http:
> //issues.apache.org/jira/browse/PLUTO-234) . So this may be a real 
> bug. Thanks for reporting it. 
> 
> Can you add a blurb on your problem to that Jira issu (PLUTO-234)? 
> If you could provide a patch, that would be great too.  We're a 
> small off-hours group here, so we appreciate any contribution you could 
make.
> 
> TIA 
> /Craig 
> 
> "alonso" <[email protected]> wrote on 12/05/2006 08:27:59 
AM:
> 
> > Hi there, I’m developing a portal application using Pluto 1.1.0-
> > beta2 embedded inside a glassfish (version 9.1) javaee application 
> > server. Embedding of the portlet container was done following same 
> > instructions than embedding pluton with Tomcat and it has been 
> > almost successfully. 
> > 
> > The portal application is deployed and running, portlets are invoked
> > through Pluto Container using the pluto-portal-driver provided with 
> > the distribution. 
> > 
> > The problem are the http sessions of the portal webapp (Top Level) 
> > and the portlet applications because if a user that was previously 
> > authenticated against the portal realm closes his http session only 
> > just the portal webapp http session is invalidated. 
> > 
> > The same problem arises when the first user is authenticated and 
> > newer one starts another session, at the portlet applications the 
> > current user is the first who was authenticated and the newer one 
> is ignored. 
> > 
> > Is this an issue related to glassfish? 
> > 
> > Does anyone know how to propagate the invalidating of the portlet 
> > app http sessions from the portal webapp? 
> > 
> > Regards 
> > Alonso