Hi Just to remember this vote is still active. There is interest in fix MYFACES-3586, but without the minimun 3 +1 votes, according to the rules I can't propose a possible patch.
regards Leonardo Uribe 2012/11/28 Leonardo Uribe <[email protected]>: > 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 <[email protected]>: >> 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 >>>> >>>
