Hi Yes, no problem. Right now I'm running the necessary steps to release myfaces core 2.0.5 (and after that tomahawk 1.1.11), so this patch will not be on 2.0.5 (but it will on 2.0.6). I want to take a look carefully to this problem and I require some time to do it. Thanks for your patch.
regards, Leonardo Uribe 2011/4/4 Martin Koci <martin.kocicak.k...@gmail.com> > Hi, > > suggested patch is here: > https://issues.apache.org/jira/browse/MYFACES-3078 > > can you please review it and apply if is it proper? > > Regards, > > Kočičák > > > Hi > > > Add a param to disable JSP support looks like a good idea. With such > > param we could solve this issue raised recently: > > > https://issues.apache.org/jira/browse/MYFACES-3104 MyFaces 2 with EL ? > > 2.2 in Websphere 7 > > > regards, > > > Leonardo Uribe > > 2011/3/17 Martin Koci <martin.kocicak.k...@gmail.com> > > This approach cannot filter two resolvers: > 1. > org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver > 2. > org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver > > > 1) the first one is instance of CompositeELResolver and serves > as > container for sorted/filtered list of others ELResolvers. > Currently does > something for JSP, so I suggest to introduce: > > o.a.m.SUPPORT_JSP = true|false > > content-param as mentioned in original mail thread "performance: > disabling "old" technologies" and if this false, myfaces will > not > install FacesCompositeELResolver, but plain > javax.el.CompositeELResolver > as parent. > > > 2) > org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver > is the > last one in chain and always calls setPropertyResolved(true); > (JSF 2.1: > 5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored > in the > request, viewScope, session, or application scopes by name. > > In strictly CDI-based application with no direct modification of > servlet > scopes or view scope this resolver will never resolve a > property. > > What to do with this one I don't know. Possibly we can use > ELResolver > transforming :) org.apache.commons.collections.Transformer and > allow > replace one resolver with another, for example: > > o.a.m.el.unified.resolver.ScopedAttributeResolver -> > MyNotResovingResolverWhichCallsSetPropertyResolvedTrue > > el.ResourceBundleELResolver -> SpringMessageSourceResolver (we > don't use > ResourceBundle) > > el.BeanELResolver -> MemoryLeakFreeBeanELResolver > > Of course this functionality can be achieved by filtering out > the > unwanted resolver with predicate and adding own in faces-config > (and > sort it to proper position in chain) > > > Regards, > > > Kočičák > > > Martin Koci píše v St 16. 03. 2011 v 11:29 +0100: > > > Hi, > > > > > > after few months I have time to do some performance > optimalization for > > myfaces. > > > > This one is related to topic > > > http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html > > > > > > Problem: > > how to disable ELResolver smartly? Adding a context-param for > each is an > > overkill. > > > > But we have > https://cwiki.apache.org/MYFACES/elresolver-ordering.html in > > codebase already. I propose to add new feature "ELResolver > filtering" > > and new context-param: > > > > <context-param> > > > <param-name>org.apache.myfaces.EL_RESOLVER_PREDICATE</param-name> > > <param-value>org.foo.bazz.ELResolverPredicate</param-value> > > </context-param> > > > > Filter is simple instance of > org.apache.commons.collections.Predicate. > > > > > > For application where no ManagedBean(Resolver) is used or no > Flash, user > > can simply return false from Predicate.evaluate and ELResolver > won't be > > installed. > > > > WDYT? > > > > Regards, > > > > Kočičák > > > > > > > > > > >
