ICEfaces
  1. ICEfaces
  2. ICE-10688

Fix session detection in ExtendedExceptionHandler for Weblogic 12

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.3, 4.0
    • Fix Version/s: EE-4.1.0.GA
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Weblogic 12
    • Assignee Priority:
      P1

      Description

      The ExtendedExceptionHandler class, who's responsibility is to interpret when a ViewExpiredException thrown by JSF implementation is caused by session expiration or indeed by an expired view, falsely reports a session expired when in fact the session is freshly created.

        Activity

        Hide
        Mircea Toma added a comment - - edited

        After running the tests I managed to reproduce this issue. The issue will occur only if previously the browser has already a JSESSIONID cookie set by other application server (for the same IP/domain). Because the JSESSIONID format is not the same Weblogic will not recognise it and assign another JSESSIONID cookie. Now when any interaction is initiated both cookies are sent, but the first one (set by another server) will be read by Weblogic and since it's not recognised it will throw a ViewExpiredException which eventually is interpeted as a session expiration.

        The solution is to cleanup the old JSESSIONID cookie before using Weblogic and everything will work fine from then on.

        Show
        Mircea Toma added a comment - - edited After running the tests I managed to reproduce this issue. The issue will occur only if previously the browser has already a JSESSIONID cookie set by other application server (for the same IP/domain). Because the JSESSIONID format is not the same Weblogic will not recognise it and assign another JSESSIONID cookie. Now when any interaction is initiated both cookies are sent, but the first one (set by another server) will be read by Weblogic and since it's not recognised it will throw a ViewExpiredException which eventually is interpeted as a session expiration. The solution is to cleanup the old JSESSIONID cookie before using Weblogic and everything will work fine from then on.
        Hide
        Liana Munroe added a comment - - edited

        Because I only have access to webLogic 12 on an amazon AWS instance I was not able to reproduce the issue. I did however run an application on a clean webLogic instance. I did not see any problems concerning false session expired reports. I forced the application to expire in 1 minute and only saw the standard session expired trace in the server log.

        ####<May 31, 2016 5:45:03 PM EDT> <Error> <javax.enterprise.resource.webcontainer.jsf.context> <ip-10-237-162-54.us-west-2.compute.internal> <ICEsoft_Administration_Server> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1464731103693> <BEA-000000> <org.icefaces.application.SessionExpiredException: session expired (causing view to expire)
                at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:123)
                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
                at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
                at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
                at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
                at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
                at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
                at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:346)
                at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
                at org.icesoft.util.servlet.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:74)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
                at org.icesoft.util.servlet.CustomHeaderFilter.doFilter(CustomHeaderFilter.java:82)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
                at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
                at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
                at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3436)
                at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3402)
                at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
                at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
                at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
                at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2285)
                at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2201)
                at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
                at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1572)
                at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:255)
                at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)
        
        Show
        Liana Munroe added a comment - - edited Because I only have access to webLogic 12 on an amazon AWS instance I was not able to reproduce the issue. I did however run an application on a clean webLogic instance. I did not see any problems concerning false session expired reports. I forced the application to expire in 1 minute and only saw the standard session expired trace in the server log. ####<May 31, 2016 5:45:03 PM EDT> <Error> <javax.enterprise.resource.webcontainer.jsf.context> <ip-10-237-162-54.us-west-2.compute.internal> <ICEsoft_Administration_Server> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1464731103693> <BEA-000000> <org.icefaces.application.SessionExpiredException: session expired (causing view to expire) at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:123) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:346) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at org.icesoft.util.servlet.RequestLoggerFilter.doFilter(RequestLoggerFilter.java:74) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at org.icesoft.util.servlet.CustomHeaderFilter.doFilter(CustomHeaderFilter.java:82) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3436) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3402) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service. SecurityManager .runAs( SecurityManager .java:120) at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57) at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2285) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2201) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1572) at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:255) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311)

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Mircea Toma
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: