myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)
Date Fri, 30 Nov 2012 18:27:53 GMT


+1

LieGrue,
strub





>________________________________
> From: Leonardo Uribe <lu4242@gmail.com>
>To: MyFaces Development <dev@myfaces.apache.org> 
>Sent: Friday, November 30, 2012 6:47 PM
>Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files
served by ResourceHandlerImpl)
> 
>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 <lu4242@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 <struberg@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.punz@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 <lu4242@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
>>>>>
>>>>
>
>
>

Mime
View raw message