Very Odd Skin Cache Issue| JBoss.org Content Archive (Read Only)

15. Re: Very Odd Skin Cache Issue

tom_goring Apr 9, 2008 5:02 AM (in response to tom_goring)

Hi,

Just to prove I'm not seeing things here is an example:

http://picbite.com/10595jgxeuz/

http://dev3.jnet.ltd.uk/S2JNET/login2.seam

I don't know how to reproduce... On the last occasion I cleared my session cookies and used the drop down to override the skin which only go applied to the panel (and not the simpleTogglePanel).

I'll have a look at firebug to see if I can send some better details.

Here is the src header of that page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<link rel='stylesheet' class='component' type='text/css' href='/S2JNET/a4j_3_2_0-SNAPSHOTorg/richfaces/renderkit/html/css/basic_classes.xcss/DATB/eAFj4tvaDgACJwFN' /><link rel='stylesheet' class='component' type='text/css' href='/S2JNET/a4j_3_2_0-SNAPSHOTorg/richfaces/renderkit/html/css/extended_classes.xcss/DATB/eAFj4tvaDgACJwFN' /><link rel='stylesheet' class='component' type='text/css' href='/S2JNET/a4j_3_2_0-SNAPSHOTcss/simpleTogglePanel.xcss/DATB/eAFj4tvaDgACJwFN' /><link rel='stylesheet' class='component' type='text/css' href='/S2JNET/a4j_3_2_0-SNAPSHOTcss/panel.xcss/DATB/eAFj4tvaDgACJwFN' /><link rel='stylesheet' class='user' type='text/css' href='/S2JNET/a4j_3_2_0-SNAPSHOTjnet-css.xcss/DATB/eAFj4tvaDgACJwFN' /><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTorg.ajax4jsf.javascript.PrototypeScript'></script><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTorg.ajax4jsf.javascript.AjaxScript'></script><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTorg.ajax4jsf.javascript.ImageCacheScript'></script><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTorg/ajax4jsf/javascript/scripts/form.js'></script><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTorg/richfaces/renderkit/html/scripts/browser_info.js'></script><script type='text/javascript' src='/S2JNET/a4j_3_2_0-SNAPSHOTscripts/simpleTogglePanel.js'></script><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="cache-control" content="no-cache" />
<title>jnet</title>
<link href="/S2JNET/stylesheet/theme.css" rel="stylesheet" type="text/css" />
<link href="/S2JNET/stylesheet/layout.css" rel="stylesheet" type="text/css" />
<link href="/S2JNET/stylesheet/elements.css" rel="stylesheet" type="text/css" />
</head>

16. Re: Very Odd Skin Cache Issue

tom_goring Apr 9, 2008 5:11 AM (in response to tom_goring)

Here is the firebug view:

http://picbite.com/10598ykcwqy/

17. Re: Very Odd Skin Cache Issue

tom_goring Apr 9, 2008 9:30 AM (in response to tom_goring)

I've updated my web.xml to include:

<context-param>
 <param-name>org.richfaces.LoadScriptStrategy</param-name>
 <param-value>DEFAULT</param-value>
 </context-param>

And I've not yet had the problem?

Also I have noticed a few CSS errors like *:
Warning: Selector expected. Ruleset ignored due to bad selector.
Source File: http://localhost:8080/S2JNET/a4j_3_2_0-SNAPSHOTorg/richfaces/renderkit/html/css/extended_classes.xcss/DATB/eAFj4tvaDgACJwFN
Line: 1

18. Re: Very Odd Skin Cache Issue

nbelaevski Apr 9, 2008 3:38 PM (in response to tom_goring)

I guess the problem is somewhere in application CSS...

Could you please deploy the example with skins dropdown menu or send war file to me to nbelaevski at exadel dot com ?

19. Re: Very Odd Skin Cache Issue

clubok Jul 22, 2013 12:50 PM (in response to tom_goring)

This is an old thread, but I am encountering the same problem, even now. (RichFaces 3.3.3 Final, but I suspect it may be in RichFaces 4 as well.) Furthermore, I have learned more about it, including how to reproduce the problem at will.

The "Hash code" that is appended to the xcss URL is specific to the skin. But the renderer does not use it to determine which skin it is rendering; it gets that from web.xml (and the appropriate skin bean property, if configured). Rather, that "hash code" is used as a cache key. The first time such a code is encountered, the xcss is rendered according to the current skin, and then cached under that key. From then on, any attempt to access that xcss with that key goes to cache, and the xcss is not rendered from the skin properties again, I believe until the server is restarted.

The problem is that, although the xcss URL code will typically be for the same skin as the current skin bean configuration, this is not guaranteed. This leads to some interesting behaviors. For example, immediately following a server restart, hit an application URL that will set your session to use the Ruby skin. Then, while your session is still set to Ruby, directly access the xcss URL with the code that is intended for BlueSky. Since your session is Ruby, you'll still get the xcss for Ruby, even though the URL had the BlueSky code. (This assumes that nobody else beats you to it by accessing the BlueSky skin first.) Furthermore, the Ruby CSS will be cached under the BlueSky code, so that until the next server restart, everybody else who tries to access the BlueSky skin will see Ruby instead.

It is possible to take this effect to rather amusing extremes. For example, one could manipulate this behavior so that for a particular skin, each of the various XCSS files renders according to a different skin's properties, giving you a glorious mish-mash of colors.

This issue can be mitigated by turning off caching in the ajax4jsf-filter option in components.xml, but you get a pretty serious performance penalty if you take that approach.

The solution, I believe, ought to be that the skin name be encoded in the xcss URL code, so that during xcss rendering it not be taken from the skin bean. That will prevent skin parameters from bleeding across to other skins' cache as I describe above.