hi martin, since we are within the core, we could use a special CompositeELResolver for it. we just need to do it if the root bean isn't mapped. as soon as the mapping is stable (mapping to an el-resolver or to a marker which indicates that the root bean can't be mapped), the el-resolver gets called directly or (if it couldn't be mapped) the existing el-resolver chain with our current CompositeELResolver gets invoked.
as jakob mentioned: we really have to do that carefully. imo we also shouldn't activate it per default. -> users who don't have a problem with the overhead of the el-resolver chain can use the existing (very solid) implementation. no - in cdi bean names are unique (because they are qualifiers). 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 Martin Koci <[email protected]> > 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 <[email protected]>: > > > 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 <[email protected]> > > >> > > >> 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 <[email protected]> > > >> > 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 <[email protected]> > > >> > > 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 > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > > > > > > > > > > > > > >
