The only _real_ solution is to not use the JSF specced resource handling and instead only use RESTful URLs. Since JSF resources may contain EL expressions, they are _not_ cacheable. We currently deliver them with a expiry of 14 days, but this is actually wrong! The RI has the same bug, so it's at least broken in the same way ;)
To shed more light on the topic you should also quote the original thread about Jakobs RelativeResourceHandler. http://markmail.org/thread/glr356g45uta5yys This contains all the really important discussions. Jakob continued his project over at google code [1] Fazit: * We must NOT cache for JSF spec compliant resource handling because the EL inside CSS, etc can change for _every_ request. * If we like to have a fully cacheable solution, then we should finally go a step back and again remove all the superfluous stuff added to commons-resourcehandler and do it cleanly. We might scan the resources for '#{' but that might become expensive as well. There was some proposal for JSF-2.2, do you have an update what happened with that? LieGrue, strub [1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/ ----- Original Message ----- > From: Werner Punz <[email protected]> > To: MyFaces Development <[email protected]> > Cc: > Sent: Wednesday, November 28, 2012 9:39 AM > Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in > jar files served by ResourceHandlerImpl) > > +1 > I have had similar situations and people definitely need a fix this has > higher priority than having no new config params. > > > Werner > > > Am 27.11.12 16:56, schrieb Leonardo Uribe: >> +1, if there are people with interest to get a problem solved, >> it's worth a shot to hear what people says and get it done. >> >> >> 2012/11/27 Leonardo Uribe <[email protected]>: >>> Hi >>> >>> Some time ago, it was mentioned the controversy behind a fix >>> for MYFACES-3586 >>> >>> > http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results >>> >>> Maybe we should reconsider the previous position about this >>> one and try to fix it, even if that means to include additional web >>> config params, even if exists better solutions for this one or >>> even if suppose more work to do. >>> >>> The reason why we should change our position is users start to >>> fall on the same hole over and over again. Given the interest on >>> the problem, it starts to sound better to provide an alternate fix >>> bundled in myfaces core instead say to the people "... setup a >>> load balancer in front of your server and cache the resources >>> there to fix your problem ...". >>> >>> Things become a ridiculousness, when you find a similar problem: >>> >>> https://issues.apache.org/jira/browse/MYFACES-3656 >>> ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true >>> >>> Both problems are similar because: >>> >>> 1. Both problems has a known solution. >>> 2. The solution is not perfect / cannot be enabled by default / there > are >>> better alternatives >>> 3. The typical answer is say "... woops ... try this alternative > strategy and >>> try to live with the problem ..." >>> >>> Given the latest feedback about MYFACES-3586 and MYFACES-3656, >>> I think it is desirable to take a look and revote a solution to this > problem >>> again. >>> >>> Please vote: >>> >>> +1 if you consider we need to fix this one once for all. >>> +0 if you don't care about >>> -1 if you consider do nothing is better and why >>> >>> Note we need minimum 3 +1 votes to support this initiative and override >>> the previous decision of the community. >>> >>> regards, >>> >>> Leonardo Uribe >> >
