hi jakob, thx for the heads-up! yes - for sure we have to be careful. in such a case we keep e.g. a list of el-resolvers which aren't allowed to get mapped (or the other way round).
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 Jakob Korherr <jakob.korh...@gmail.com> > 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 >
