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
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
>
