Caching resource bug

[ivan_ra]

I found strange caching resource bug with richfaces + jboss portlet bridge.

Maybe not bridge bug, but lets look:

• download portlet bridge 2.2
• deploy richFacesPortlet.war from portlet bridge archive (i used jboss portal 2.7.2 bundle)
• look at network activity (i did with firefox + firebug, the same result on any other browser). Just open page with richfaces portlet.

When user is not logged in, all richfaces resources are caching well, and this is headers returned by server:

GET richFacesPortletWi...faces%2Fui.pack.js	200 OK	localhost:8080	661.5 KB		230ms
Cache-Control max-age=86400 Content-Type text/javascript Date Thu, 26 Jan 2012 17:57:39 GMT Expires 27 Jan 2012 17:57:39 GMT Last-Modified 26 Jan 2012 17:42:17 GMT Server Apache-Coyote/1.1 X-Powered-By Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0

This time all data come from saved cache.

But when user is logged in all richfaces stuff come from network every time (more than 1.3 mb).

This is headers returned by server when user logged in:

GET richFacesPortletWi...faces%2Fui.pack.js	200 OK	localhost:8080	661.5 KB	127.0.0.1:8080	658ms
Cache-Control no-cache, max-age=86400 Content-Type text/javascript Date Thu, 26 Jan 2012 18:26:49 GMT Expires Thu, 01 Jan 1970 03:00:00 MSK, 27 Jan 2012 18:26:49 GMT Last-Modified 26 Jan 2012 18:05:56 GMT Pragma No-cache Server Apache-Coyote/1.1 Transfer-Encoding chunked X-Powered-By Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0

Is it possible to get right headers for richfaces resources? Without it richfaces are useless in secured portlets because generate too much unnessessary traffic

[kenfinni]

I don't think I've seen anything like that occur before.

Can you try the PortletBridge with GateIn instead of JBoss Portal, as it may be related to the Portal Container as opposed to the PortletBridge?

Ken

[ivan_ra]

The same problem with GateIn-3.1.0-FINAL-jbossas bundle, but now only one wrong header:

Cache-Control	max-age=86400
Content-Type	text/javascript;charset=UTF-8
Date	Sat, 28 Jan 2012 08:54:14 GMT
Expires	29 Jan 2012 08:54:14 GMT
Last-Modified	28 Jan 2012 08:51:11 GMT
Pragma	No-cache
Server	Apache-Coyote/1.1
Transfer-Encoding	chunked
X-Powered-By	Servlet 2.5; JBoss-5.0/JBossWeb-2.1

This header (Pragma) appears only when user is logged in, and again, all richfaces resources come through network.

I did some debug and found that bridge create good headers, but someone put wrong values into real response before it. I cant find this code in portal sources, so maybe it is JBoss AS problem, or third party component.

Wrong headers appears only when user is logged in.

Cant find root of problem, but can correct real response

I've made patch for portal-core-lib.jar (2.7.2) which work for me:

class org.jboss.portal.core.controller.handler.HTTPResponse has 2 methods sendBinary(...) with inner anonymous classes with code like this:

            if (properties != null)
            {
                      for (String key: properties.keySet())
                      {
                                if (properties.getValue(key) != null)
                                {
                                    resp.addHeader(key, properties.getValue(key));
                                }
                      }
            }

the patch for this code is:

            if (properties != null)
            {
                      for (String key: properties.keySet())
                      {
                                if (properties.getValue(key) != null)
                                {
                                    resp.setHeader(key, properties.getValue(key));
                                }
                      }
                      String key = "Pragma";
                      resp.setHeader(key, properties.getValue(key));
            }

I think the same patch available for gatein portal too

[ivan_ra]

I looked for gatein sources and found that same headers workaround already made.

This is code from org.exoplatform.portal.webui.application.UIPortletActionListener$ServeResourceActionListener:

            //
            //Manage headers
            if (piResponse.getProperties() != null && piResponse.getProperties().getTransportHeaders() != null)
            {
               MultiValuedPropertyMap transportHeaders = piResponse.getProperties().getTransportHeaders();
               Map headers = new HashMap();
                for (String key : transportHeaders.keySet())
               {
                  for (String value : transportHeaders.getValues(key))
                  {
                     headers.put(key, value);
                  }
               }
               context.setHeaders(headers);
            }

By this way gatein overwrites all headers using transportHeaders values, as i suggested for jboss portal 2.7.2. The only problem is Pragma=No-cache header.

So, i suggest another workaround (now for richfaces). Richfaces must set empty pragma for transportHeaders in method

org.ajax4jsf.resource.InternetResourceBase.sendHeaders(ResourceContext context): add this string

        if (cached) {

            ...

            context.setHeader("Pragma", "");

        }

After richfaces patching gatein portal working well, jboss portal still needs for patch like this:

            if (properties != null)
            {
                      for (String key: properties.keySet())
                      {
                                if (properties.getValue(key) != null)
                                {
                                    resp.setHeader(key, properties.getValue(key));
                                }
                      }
            }

Now, i think it's completly richfaces bug and workaround (+jboss for legacy projects). Should i have to make new topic in richfaces forum or its possible to move it there?

[kenfinni]

It might be best to simply create a new forum thread in RichFaces so as not to confuse them with Portal details, as it now sounds like your problem is purely related to RichFaces.

Ken