Page Comparison

In order to make the Portlet adapter as efficient as possible, a caching strategy was implemented that is beyond the scope of the Portlet's control. It works as follows: uPortal will cache the contents of a Portlet screen until one of the following occurs:

• The user clicks on a link or button within the Portlet.
• The user clicks on a button within the Portlet control bar, i.e. Edit, Help, About, etc.
• The Portlet is focused or unfocused, i.e. the Portlet alternates between being the root of the layout and not the root of the layout.
• A PortalEvent is sent to the Portlet.

When one of these activities occurs, it usually triggers a state change within the Portlet, and the new screen is cached until one of these activities happens again. Therefore, simply clicking refresh on your browser will not cause the Portlet to render itself again. The optional Portlet caching settings mentioned in the Portlet Specification are not implemented at this timeuPortal supports all of the JSR-168 and JSR-286 caching features.

Expiration Based Caching

Portlets can specify an expiration timeout, in seconds, in their portlet.xml or via a response property or via the CacheControl API. When an expiration time is set the portal will return the cached content for the portlet until the expiration time passes OR until the user directly interacts with the portlet.

Validation (ETag) Caching

Portlets can specify an ETag along with expiration time on render and resource responses which are used to represent the state of the response. Subsequent requests with the ETag and the portlet can simply respond that the cached content is still good. Validation caching also allows the portlet to mark specific responses as public or private scoped, publicly scoped data may be shared between multiple users.

uPortal takes these ETag related features as far as possible to improve performance with resource responses getting the biggest benefit.

• When a portlet sets an ETag on any response with an expiration time the portal caches the content using the ETag, until the expiration time passes any subsequent request for the same ETag results in immediate replay from cache
• One the expiration time for an ETagged response has passed the portlet is consulted to see if the ETag is still valid for the request, if the portlet returns true the content is replayed and the cache expiration updated.
• On resource responses the ETag is passed to the browser as the ETag HTTP header

More Information

For a complete description of how portlet caching works it is recommended to read section PLT.22 of the JSR-286 specification.

Caching of static assets

uPortal and some portlets are configured to cache static assets such as *.js and *.css configuration in web.xml, a spring context file, and ehcache.xml, for example.  

<filter>
    <filter-name>pageCachingFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>targetFilterLifecycle</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
    
<filter-mapping>
    <filter-name>pageCachingFilter</filter-name>
    <url-pattern>*.js</url-pattern>
    <url-pattern>*.css</url-pattern>
</filter-mapping>

Other configuration is needed in applicationContext.xml and ehcache.xml, and you typically also use a cacheExpiresFilter  See the following for examples:

• https://github.com/Jasig/CalendarPortlet/blob/CalendarPortlet-2.1.3-M4/src/main/webapp/WEB-INF/web.xml#L86
• https://github.com/Jasig/CalendarPortlet/blob/CalendarPortlet-2.1.3-M4/src/main/webapp/WEB-INF/context/applicationContext.xml#L61
• https://github.com/Jasig/CalendarPortlet/blob/CalendarPortlet-2.1.3-M4/src/main/resources/ehcache.xml#L38