Hi This vote is only for fix the performance problem over the default ResourceHandlerImpl bundled in MyFaces Core. The idea is create a temporal folder and uncompress the resources there. Also, adopt the idea of use a soft reference map to avoid read the file, but that memory cache needs some rules.
In theory, nothing has happened in JSF 2.2, but Jakob, should know that better than me (I don't see any changes on the spec for this part). I know there are more problems and tha a full solution for ResourceHandler stuff is use only RESTful URLs, but that's for another discussion. We need a proposal and check point by point what to do, but that's for another discussion. If you want to start the discussion, please do it but in another mail, because it is a different topic. EL expressions inside css files are considered application-scoped, which means once evaluated they never change. It is not a problem for the cache here. The solution proposed is feasible, but it cannot be enabled by default. Please vote +1, +0 or -1 over provide a fix for MYFACES-3586 inside MyFaces Core. regards, Leonardo Uribe 2012/11/28 Mark Struberg <strub...@yahoo.de>: > 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 <werner.p...@gmail.com> >> To: MyFaces Development <dev@myfaces.apache.org> >> 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 <lu4...@gmail.com>: >>>> 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 >>> >>
