+1
On Fri, Nov 30, 2012 at 9:47 AM, Leonardo Uribe <lu4...@gmail.com> wrote: > 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 <lu4...@gmail.com>: > > 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 > >>>> > >>> > -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
