Uploaded image for project: 'Jetspeed 2'
  1. Jetspeed 2
  2. JS2-932

Portlet cache doesn't get refresh after login

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.1, 2.1.2, 2.1.3, 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      Tomcat,mysql

      Description

      Portlet cache doesn't get refresh after login. Portlet keep on showing old content until we perform some
      action on portlet.

        Activity

        Hide
        taylor David Sean Taylor added a comment -

        I changed the default setting for creating new sessions upon authentication. This should fix the problem. Please retest from the trunk and close if it also works for you. Thanks

        <bean id='org.apache.jetspeed.administration.PortalAuthenticationConfiguration'
        class='org.apache.jetspeed.administration.PortalAuthenticationConfigurationImpl'>

        <!-- create new session upon authentication -->
        <constructor-arg index='0'>
        <value>false</value>
        </constructor-arg>

        Show
        taylor David Sean Taylor added a comment - I changed the default setting for creating new sessions upon authentication. This should fix the problem. Please retest from the trunk and close if it also works for you. Thanks <bean id='org.apache.jetspeed.administration.PortalAuthenticationConfiguration' class='org.apache.jetspeed.administration.PortalAuthenticationConfigurationImpl'> <!-- create new session upon authentication --> <constructor-arg index='0'> <value>false</value> </constructor-arg>
        Hide
        adouma Ate Douma added a comment -

        While I expect this change to fix it for now, it might not be enough afterall with regards to other (new) requirements which we'll have to deal with too.
        For instance, the portlet 2.0 spec added shared content caching options (optional) as well as ETag based content caching, see: JS2-952
        Full support of those features is only scheduled for the next 2.2.1 release however.
        Additionally, if a new session is not created upon authentication (maybe when implementing something like a shopping-card solution) this would still remain an issue too.

        Show
        adouma Ate Douma added a comment - While I expect this change to fix it for now, it might not be enough afterall with regards to other (new) requirements which we'll have to deal with too. For instance, the portlet 2.0 spec added shared content caching options (optional) as well as ETag based content caching, see: JS2-952 Full support of those features is only scheduled for the next 2.2.1 release however. Additionally, if a new session is not created upon authentication (maybe when implementing something like a shopping-card solution) this would still remain an issue too.
        Hide
        firevelocity Vivek Kumar added a comment -

        This issue fixed in jetspeed trunk.

        Show
        firevelocity Vivek Kumar added a comment - This issue fixed in jetspeed trunk.
        Hide
        firevelocity Vivek Kumar added a comment -

        Issue is fixed

        Show
        firevelocity Vivek Kumar added a comment - Issue is fixed
        Hide
        adouma Ate Douma added a comment -

        The real cause of this issue, not evicting user content caches upon authentication, is still not fixed when not creating a new session upon authentication (although that's the default now).

        As I'm deep in the content cache handling already for integrating public render parameters cache management, I noticed we do have the proper evicting already coded upon session invalidation within JetspeedServlet.

        As the evicting requires 3 different Spring components and several lines of logic, I'll move the code from JetspeedServlet to a new UserContentCacheManager with a single evictUserContentCache method.
        This method then needs to be invoked from the following situations:

        • JetspeedServlet.sessionDestroyed
        • LoginRedirectorServlet.doGet (after container authentication)
        • PortalFilter and ShibbolethPortalFilter doFilter (after custom authentication)
        • and should also be called by any other custom PortalFilter

        Configuration of the UserContentCacheManagerImpl will be done in cache.xml

        Show
        adouma Ate Douma added a comment - The real cause of this issue, not evicting user content caches upon authentication, is still not fixed when not creating a new session upon authentication (although that's the default now). As I'm deep in the content cache handling already for integrating public render parameters cache management, I noticed we do have the proper evicting already coded upon session invalidation within JetspeedServlet. As the evicting requires 3 different Spring components and several lines of logic, I'll move the code from JetspeedServlet to a new UserContentCacheManager with a single evictUserContentCache method. This method then needs to be invoked from the following situations: JetspeedServlet.sessionDestroyed LoginRedirectorServlet.doGet (after container authentication) PortalFilter and ShibbolethPortalFilter doFilter (after custom authentication) and should also be called by any other custom PortalFilter Configuration of the UserContentCacheManagerImpl will be done in cache.xml
        Hide
        adouma Ate Douma added a comment -

        Fixed

        Show
        adouma Ate Douma added a comment - Fixed

          People

          • Assignee:
            adouma Ate Douma
            Reporter:
            firevelocity Vivek Kumar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development