hi martin, i think most users will be fine with the OpenWebBeansELResolverComparator [1] and a custom InterceptorHandler (btw. an add-on like the scope-boost for codi). (esp. because an implicit variable would also break e.g. ide support.)
however, if you have concrete numbers, we could start a vote about it. 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 > > > > > > > > >
