7 Replies Latest reply on Mar 10, 2011 2:04 PM by mstruk

    GateIn Session Handling - Seam

    andre.winkler

      If I log out in GateIn, the portlet sessions get not invalidated... why?

       

      The new SessionInvalidatorInterceptor purges the session, but that makes no sense and works not for portlets with seam and richfaces.

      Why do you do not invalidate the session?

       

      Can I implement a workaround for the GateIn version 3.1.0 GA?

        • 1. GateIn Session Handling - Seam
          pking

          Hi,

           

          I just was traversing through the forum and came accross your post. We have tried to compile and deploy GateIn3.2 sources, but still the problem occures, even though https://issues.jboss.org/browse/GTNPORTAL-1257 says it should be fixed.

           

          If succeed we'll let you know how to get it works.

           

           

          cheers,

          P.

          • 2. GateIn Session Handling - Seam
            theute

            The solution that is committed clean the sessions (doesn't destroy) but doesn't do it if you connect with the same user.

             

            A new solution is coming up and is currently devevelopped in a branch, it's part of WCI component as it is server specific (Servlet spec doesn't really like what portals do with multiple applications )

             

            http://anonsvn.jboss.org/repos/gatein/components/wci/branches/logout/

             

            You can give it a try if you want

            • 3. GateIn Session Handling - Seam
              mstruk

              Quick instructions on how to give it a try ... You have to use specific revision as the latest changes break compatibility with portal trunk:

               

              svn co -r5921 http://anonsvn.jboss.org/repos/gatein/components/wci/branches/logout/ wci-logout-r5921

              cd wci-logout-r5921

              mvn clean install -Dmaven.test.skip

               

              Now go to your gatein trunk sources, and change wci component version in portal-parent pom.xml:

               

              cd portal/trunk

              vi pom.xml

               

              Change wci version to:

               

              <org.gatein.wci.version>2.1.0-Alpha04-SNAPSHOT</org.gatein.wci.version>

               

              And rebuild / repackage gatein:

               

              mvn clean install -Ppkg-jbossas5 -Dmaven.test.skip -Dexo.projects.directory.dependencies=$DEPENDENCIES_DIR

               

               

               

              The gist of the solution is revision 5907 (svn diff -r5907). To use it with GateIn 3.1 it would have to be ported to wci-2.0.1-GA (http://anonsvn.jboss.org/repos/gatein/components/wci/tags/2.0.1-GA).

              • 4. GateIn Session Handling - Seam
                buczyn

                Thank you for the tips.

                I have tried to user wci from logout branch in revision 5907. I had some problems because gatein required wci-tomcat jar, which was not created during build process (the wci-tomcat6 and wci-tomcat7 jars were created). What I did is just install the wci-tomcat6 jar manually in the maven repository as wci-tomcat. Then I was able to build the gatein. Unfortunatelly it does not solve the problem. The Seam session context is not cleared after logout.

                 

                I have found similar topic: http://community.jboss.org/message/580701#580701. Removing SeamFilter configuration in web.xml really works, the seam session context is cleared, but of course without SeamFilter some Seam functionalities does not work.

                 

                Looking at the changes made on logout branch, I think this is just some way to switch off the invalidating the session, but the session invalidation works already or I miss something. If the invalidation is really there, so maybe the problem with Seam is not in the wci component? Maybe it is more portlet bridge issue? Unfortunately I don't know all those components (wci, gatein, portalbridge) and really don't know where look for the answer. I would be grateful if you could put some light on it and give some ideas. Currently it is really blocker issue, making seam almost useless for portlet development in GateIn.

                 

                Thanks,

                J.

                • 5. Re: GateIn Session Handling - Seam
                  mstruk

                  Jacek Bukowski wrote:

                   

                  Thank you for the tips.

                  I have tried to user wci from logout branch in revision 5907. I had some problems because gatein required wci-tomcat jar, which was not created during build process (the wci-tomcat6 and wci-tomcat7 jars were created). What I did is just install the wci-tomcat6 jar manually in the maven repository as wci-tomcat. Then I was able to build the gatein.

                   

                  If you've been building portal trunk, then there should be no dependency on wci-tomcat. The result of your build should be in packaging/jboss-as5/pkg/target/jboss, and if you look there in server/default/deploy/gatein.ear/lib you should see the following jar: wci-tomcat6-2.1.0-Alpha04-SNAPSHOT.jar.

                   

                  Based on what you wrote It seems quite possible that you weren't actually using the correct wci.

                   

                  Can you please check so that we can be sure ...

                   

                  Otherwise, the best way you can help us get to the bottom of this is to create a simple .war that demonstrates the problem, and attach it to the JIRA.

                  • 6. Re: GateIn Session Handling - Seam
                    buczyn

                    You had right. I was using not trunk gatein. When I switched I was able to build it. It seems to work, I mean the session is invalidated. The only thing is that Seam does not correctly handle this. I get:

                    14:52:43,935 ERROR [[/session-web]] Session event listener threw exception
                    java.lang.IllegalStateException: Please end the HttpSession via org.jboss.seam.web.Session.instance().invalidate()
                            at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:267)
                            at org.jboss.seam.contexts.ServletLifecycle.endSession(ServletLifecycle.java:187)
                            at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:59)
                            at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702)
                            at org.apache.catalina.session.StandardSession.expire(StandardSession.java:660)
                            at org.gatein.wci.tomcat.TC6WebAppContext.invalidateSession(TC6WebAppContext.java:140)
                            at org.gatein.wci.impl.DefaultServletContainer$WebAppImpl.invalidateSession(DefaultServletContainer.java:447)
                            at org.gatein.wci.tomcat.TC6ServletContainerContext$1.accept(TC6ServletContainerContext.java:130)
                            at org.gatein.wci.impl.DefaultServletContainer.visit(DefaultServletContainer.java:276)
                            at org.gatein.wci.tomcat.TC6ServletContainerContext.logout(TC6ServletContainerContext.java:126)
                            at org.gatein.wci.impl.DefaultServletContainer.logout(DefaultServletContainer.java:118)
                            at org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:60)
                            at org.exoplatform.portal.application.PortalLogoutLifecycle.onEndRequest(PortalLogoutLifecycle.java:37)
                            at org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:151)
                            at org.exoplatform.web.WebAppController.service(WebAppController.java:165)
                            at org.exoplatform.portal.application.PortalController.onService(PortalController.java:127)
                            at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
                            at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
                            at org.exoplatform.sample.ext.web.SampleFilter.doFilter(SampleFilter.java:46)
                            at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:106)
                            at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:80)
                            at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:79)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:72)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionPro
                    viderInitializedFilter.java:116)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:90)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:73)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
                            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
                            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
                            at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
                            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
                            at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
                            at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.jav
                    a:126)
                            at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java
                    :70)
                            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
                            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
                            at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
                            at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
                            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
                            at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
                            at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
                            at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
                            at java.lang.Thread.run(Thread.java:619)
                    

                     

                    But from the functionality point of view the session is cleared and I don't see old data.

                    • 7. GateIn Session Handling - Seam
                      mstruk

                      I tried to reproduce this IllegalStateException without success. I used Booking example that comes with JBoss Portlet Bridge (JBP), and I see no issues when logout is performed.

                       

                      Maybe the way you deploy Seam isn't appropriate for portal environment - specifically the SeamListener ... maybe some other listener should be installed before it, or maybe some other JBP listener should be used instead.

                       

                      Can you put together a simple .war that demonstrates the issue?