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 >> > > >> > > >> > > >> > >> > >> > >> > >> > >> >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
