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
