hi leo, we don't have control over the performance of custom el-resolvers. the comparator would help but then we are again at the point mentioned by martin.
for sure we can do both. to get a first impression, we don't have to prototype all edge cases. e.g. we can test it by just mapping a custom el-resolver (e.g. the owb el-resolver). that doesn't take that much time (if it works at all). however, maybe martin can provide some concrete numbers. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/8/9 Leonardo Uribe <lu4...@gmail.com> > Hi > > 2011/8/9 Gerhard Petracek <gerhard.petra...@gmail.com>: > > hi leo, > > that's why i asked martin concerning results and he answered that he can > see > > a big difference. > > currently we just think about different approaches. that doesn't mean > that > > we commit something to the trunk within the next days. > > if we prototype such an improvement, we have to do it e.g. in a branch > and > > measure the differences (just a real comparison will show the difference > and > > no theoretical discussion). > > Yes, but note a comparison against some ELResolvers without review > them could lead to wrong conclusions. First we need to check if the > current implementation of our ELResolvers runs fast enough and then do > the comparison. > > Anyway I don't understand why try an optimization without know how it > can enhance performance. It sound like a trial and error approach, and > probably it will waste a lot of time and resources that can be saved > with a good analysis. > > regards, > > Leonardo Uribe > > > regards, > > gerhard > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > > > > 2011/8/9 Leonardo Uribe <lu4...@gmail.com> > >> > >> Hi > >> > >> I have doubts about if we are really looking on the real source of the > >> problem, or if some hack can improve the speed of the code. In theory > >> each EL resolver do a quick-check before do the real work. Thinking > >> about a solution based on the previous comments, I don't see where is > >> the improvement, because after all, we need to do all the steps that > >> are doing the chain right now. > >> > >> I think the trick is check carefully each resolver and what is doing, > >> and enhance that part. Remember that is "expensive" is not an > >> interation over an array, is the comparisons, lookups to maps or other > >> code that is executed over and over. > >> > >> regards, > >> > >> Leonardo Uribe > >> > >> 2011/8/9 Martin Koci <martin.kocicak.k...@gmail.com>: > >> > Hi, > >> > > >> > I also agree (with Gerhard) that in first place it is better to some > >> > improvements in myfaces core (without unnecessary burden for clients). > >> > > >> > > >> > But it is not easy (or even possible?) to intercept EL expression > >> > evaluation, because the only API we can use in myfaces is ELResolver > and > >> > method getValue. Evaluation of EL Expression itself is internal part > of > >> > EL impl and I don't see any elegant way how to detect that evaluated > >> > base or property in ELResolver.getValue() is root bean or not. Any > >> > ideas? > >> > > >> > > >> > More about custom imlicit objects: > >> > I still think that the idea is good and myfaces or JSF generally > should > >> > support it. Use cases: > >> > > >> > 1) Custom implicit object for render kits and JSF libraries like > "skin". > >> > For example, richfaces have own ELResolver and they use a managed > bean > >> > in it [1]. > >> > > >> > 2) project-specific implicit object. Many projects has something like > >> > "projectConfiguration" with properties like version: > >> > #{projectConfiguration.version}. Currently the projectConfiguration > must > >> > be managed-bean or IoC container (CDI, Spring) managed and named bean. > >> > With possibility of custom implicit object, project can define own > names > >> > and optimize EL resolving for object where managed bean is an > performace > >> > overhead (configuration in this example can be a instance of > Properties > >> > and completely unmanaged). Imlicit object is de facto a well-known > >> > build-in named bean. > >> > > >> > 3) Jakob mentioned JSF managed-beans. In this case two managed beans > can > >> > have same name and different scope. User can specify > >> > #{sessionScope.sameName} and #{requestScope.sameName} to differentiate > >> > them. It this possible for CDI beans too? > >> > > >> > Everything has advantages and disadvatages and I think (custom) > implicit > >> > objects is underestimated area in JSF that has it's purpose in > specific > >> > use cases. > >> > > >> > Regards, > >> > > >> > Kočičák > >> > > >> > [1] https://issues.jboss.org/browse/RF-10755 > >> > > >> > Jakob Korherr píše v Út 09. 08. 2011 v 19:35 +0200: > >> >> Hi, > >> >> > >> >> That's a good idea, however we need to be very careful with such > >> >> improvements. There are some cases in which you need different EL > >> >> resolvers for the "same" object. For example, JSF managed beans are > >> >> created by the ManagedBean EL resolver (very late in the chain), but > >> >> if they already exist, they are resolved by the respective scope EL > >> >> resolver (e.g. session EL resolver for @SessionScoped managed beans). > >> >> > >> >> Please keep that in mind! > >> >> > >> >> Regards, > >> >> Jakob > >> >> > >> >> 2011/8/8 Gerhard Petracek <gerhard.petra...@gmail.com>: > >> >> > hi martin, > >> >> > a smarter approach might be useful. e.g. after the first lookup of > a > >> >> > root-bean myfaces-core could store the el-resolver which found the > >> >> > bean in a > >> >> > mapping. > >> >> > before the resolver chain gets invoked, myfaces-core could do a > >> >> > lookup in > >> >> > the stored mapping and use the mapped el-resolver (if there is > one). > >> >> > if the > >> >> > el-resolver can't resolve the bean any more (or there is no mapped > >> >> > el-resolver), the whole chain would be invoked as usual. > >> >> > regards, > >> >> > gerhard > >> >> > > >> >> > http://www.irian.at > >> >> > > >> >> > Your JSF powerhouse - > >> >> > JSF Consulting, Development and > >> >> > Courses in English and German > >> >> > > >> >> > Professional Support for Apache MyFaces > >> >> > > >> >> > > >> >> > > >> >> > 2011/8/8 Martin Koci <martin.kocicak.k...@gmail.com> > >> >> >> > >> >> >> Gerhard Petracek píše v Po 08. 08. 2011 v 16:36 +0200: > >> >> >> > hi martin, > >> >> >> > > >> >> >> > > >> >> >> > i think most users will be fine with the > >> >> >> > OpenWebBeansELResolverComparator [1] > >> >> >> > >> >> >> yes, this comparator moves OWB resolver to the last posititon. > Thas > >> >> >> good > >> >> >> because most of the EL expression nodes are generally not cdi > beans > >> >> >> names. Custom implicit object was only proposition how to specify > >> >> >> that > >> >> >> following node in expression is CDI bean. > >> >> >> > >> >> >> > and a custom InterceptorHandler (btw. an add-on like the > >> >> >> > scope-boost > >> >> >> > for codi). > >> >> >> I'll take a look at it. > >> >> >> > >> >> >> > (esp. because an implicit variable would also break e.g. ide > >> >> >> > support.) > >> >> >> > > >> >> >> yes, that is a disadvantage. But generally IDEs must support > >> >> >> something > >> >> >> like that, because custom scopes are possible in JSF 2.0 > >> >> >> > >> >> >> > however, if you have concrete numbers, we could start a vote > about > >> >> >> > it. > >> >> >> > > >> >> >> > >> >> >> with 100 000 and more invocation of CompositeELResolver.getValue > >> >> >> during > >> >> >> one render response is improvement noticeable, especially if every > >> >> >> EL > >> >> >> expression is #{someCDIBean.someProperty} > >> >> >> > >> >> >> But I incorrectly mixed together two problems: > >> >> >> > >> >> >> 1) posibility of custom implicit objects for myfaces core, > >> >> >> independent > >> >> >> from usage. > >> >> >> > >> >> >> 2) example of usage : CDI/CODI integration. > >> >> >> > >> >> >> > > >> >> >> > regards, > >> >> >> > gerhard > >> >> >> > > >> >> >> > > >> >> >> > [1] > https://cwiki.apache.org/confluence/display/MYFACES/ELResolver > >> >> >> > +ordering > >> >> >> > > >> >> >> > http://www.irian.at > >> >> >> > > >> >> >> > Your JSF powerhouse - > >> >> >> > JSF Consulting, Development and > >> >> >> > Courses in English and German > >> >> >> > > >> >> >> > Professional Support for Apache MyFaces > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > 2011/8/8 Martin Koci <martin.kocicak.k...@gmail.com> > >> >> >> > Hi, > >> >> >> > > >> >> >> > > >> >> >> > the OWB el-resolver itself is fast enough, thats not the > >> >> >> > problem. The > >> >> >> > problem is when you use CDI managed bean in big > ELResolver > >> >> >> > chain. For > >> >> >> > example, consider this chain: > >> >> >> > > >> >> >> > ImplicitObjectResolver > >> >> >> > MapELResolver > >> >> >> > ResourceResolver > >> >> >> > CompositeComponentELResolver > >> >> >> > VariableResolverToELResolver > >> >> >> > PropertyResolverToELResolver > >> >> >> > FlashELResolver > >> >> >> > ManagedBeanResolver > >> >> >> > ResourceBundleELResolver > >> >> >> > ResourceBundleResolver > >> >> >> > ListELResolver > >> >> >> > ArrayListResolver > >> >> >> > org.apache.webbeans.el.WebBeansELResolver > >> >> >> > SkinPropertiesELResolver > >> >> >> > ResourceParametrELResolver > >> >> >> > javax.el.BeanELResolver > >> >> >> > > >> >> >> > then when resolving #{cdiScopeBean} EL impl must call > >> >> >> > first 12 > >> >> >> > resolvers > >> >> >> > and none of them sets > elContext.setPropertyResolved(true) > >> >> >> > > >> >> >> > Old JSF style can shorten it with > >> >> >> > #{sessionScope.sessionScopedBean} for > >> >> >> > example and then resolving takes only first two > resolvers > >> >> >> > because > >> >> >> > MapELResolver sets propertyResolved(true) > >> >> >> > > >> >> >> > so I'm looking for a solution how to minimize "void" > usage > >> >> >> > of > >> >> >> > ELresolvers and how to say directly that "this is CDI > bean > >> >> >> > and > >> >> >> > use CDI > >> >> >> > ELResolver for it" > >> >> >> > > >> >> >> > > >> >> >> > Gerhard Petracek píše v Po 08. 08. 2011 v 15:50 +0200: > >> >> >> > > >> >> >> > > hi martin, > >> >> >> > > > >> >> >> > > > >> >> >> > > the real overhead (after our recent improvements) is > the > >> >> >> > overhead of > >> >> >> > > the proxy itself. > >> >> >> > > > >> >> >> > > > >> >> >> > > in owb we have a cache in the el-resolver as well as > in > >> >> >> > > some implementations of InterceptorHandler. the > upcoming > >> >> >> > version of > >> >> >> > > owb will allow to use such special caches also for > >> >> >> > custom > >> >> >> > scopes. > >> >> >> > > e.g. there is a scope-boost add-on [1] for codi. so > you > >> >> >> > get > >> >> >> > contextual > >> >> >> > > instances which are cached in a thread-local and the > >> >> >> > add-on > >> >> >> > also has > >> >> >> > > to do the reset of the cache (as soon as it is needed > - > >> >> >> > that > >> >> >> > depends > >> >> >> > > on the concrete scope). > >> >> >> > > > >> >> >> > > > >> >> >> > > since we already have two caches in place and the real > >> >> >> > overhead is in > >> >> >> > > the proxy implementation, i'm not sure if we really > get > >> >> >> > more > >> >> >> > > performance with such a spi. > >> >> >> > > > >> >> >> > > > >> >> >> > > (mark also implemented a cache for methods which > aren't > >> >> >> > intercepted. i > >> >> >> > > already tested it and depending on the constellation > the > >> >> >> > increase in > >> >> >> > > performance is about 5%.) > >> >> >> > > > >> >> >> > > > >> >> >> > > regards, > >> >> >> > > gerhard > >> >> >> > > > >> >> >> > > > >> >> >> > > [1] > >> >> >> > > >> >> >> > > >> >> >> > > http://os890.blogspot.com/2011/08/benchmark-boost-myfaces-codi-scopes.html > >> >> >> > > > >> >> >> > > http://www.irian.at > >> >> >> > > > >> >> >> > > Your JSF powerhouse - > >> >> >> > > JSF Consulting, Development and > >> >> >> > > Courses in English and German > >> >> >> > > > >> >> >> > > Professional Support for Apache MyFaces > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > 2011/8/8 Martin Koci <martin.kocicak.k...@gmail.com> > >> >> >> > > Hi, > >> >> >> > > > >> >> >> > > if user uses plain old JSF style with managed > >> >> >> > beans > >> >> >> > like: > >> >> >> > > > >> >> >> > > #{sessionScope.mySessionScopedBean} or > >> >> >> > > #{requestScope.myRequestScopedBean} or > >> >> >> > > #{requestScope.varFromDataTable.property} > >> >> >> > > > >> >> >> > > it can achieve excellent performance during > >> >> >> > render > >> >> >> > response > >> >> >> > > phase, > >> >> >> > > because every EL resolution takes only two > >> >> >> > steps: > >> >> >> > > > >> >> >> > > 1) o.a.m.ImplicitObjectResolver resolves > >> >> >> > sessionScope or > >> >> >> > > requestScope to > >> >> >> > > java.util.Map > >> >> >> > > 2) javax.el.MapELResolver reads > >> >> >> > map.get("mySessionScopedBean") > >> >> >> > > and sets > >> >> >> > > elContext.setPropertyResolved > >> >> >> > > > >> >> >> > > (at first access ManagedBeanResolver must > create > >> >> >> > bean instance > >> >> >> > > but we > >> >> >> > > can ignore it for simplicity). > >> >> >> > > > >> >> >> > > Specially if user uses EL resolvers ordering > [1] > >> >> >> > and creates > >> >> >> > > chain of > >> >> >> > > (ImlicitObjectResolver,MapELResolver, other > >> >> >> > resolvers) then > >> >> >> > > resolving > >> >> >> > > takes only two first resolvers. > >> >> >> > > > >> >> >> > > > >> >> >> > > Now compare it with situation where CDI is > used. > >> >> >> > Because > >> >> >> > > CDI/OWB > >> >> >> > > resolver is not so fast as default el > resolvers, > >> >> >> > common usage > >> >> >> > > is put it > >> >> >> > > at bottom of resolvers chain with > >> >> >> > > OpenWebBeansELResolverComparator. Then > >> >> >> > > resolving must go thru all ELresolvers in > chain > >> >> >> > (12 > >> >> >> > or more > >> >> >> > > resolvers) > >> >> >> > > to find a @Named bean. > >> >> >> > > > >> >> >> > > > >> >> >> > > How to improve this? One thing can be use > custom > >> >> >> > implicit > >> >> >> > > object for > >> >> >> > > this > >> >> >> > > 1) create ImplicitObjectsProvider SPI > interface > >> >> >> > in > >> >> >> > myfaces > >> >> >> > > 2) CDI and CDI extension will add own > >> >> >> > implementation > >> >> >> > of > >> >> >> > > myfaces > >> >> >> > > ImlicitObject, for example #{codiWindowScope} > >> >> >> > from > >> >> >> > CODI > >> >> >> > > 3) the resolved value from implicit object can > >> >> >> > mimic > >> >> >> > the map > >> >> >> > > interfaces > >> >> >> > > (for example WindowScopeMap) to preserve > >> >> >> > behaviour > >> >> >> > of servlet > >> >> >> > > scopes and > >> >> >> > > to use MapELResolver > >> >> >> > > > >> >> >> > > WDYT? Any other ideas? > >> >> >> > > > >> >> >> > > > >> >> >> > > Regards, > >> >> >> > > > >> >> >> > > Kočičák > >> >> >> > > > >> >> >> > > [1] > >> >> >> > > https://cwiki.apache.org/MYFACES/elresolver-ordering.html > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > > > > > >
