[core] performance: custom implicit objects

[Martin Koci <ma...@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

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

hi leo,

i already implemented a first prototype for cdi beans. it was just a matter
of minutes.

i just have to impl. a benchmark which uses a mixture of different bean
types to measure the difference.
i'll post the first results soon. everybody who is interested in doing own
tests (before i share a stable link which shows all details) can follow me
on my people-account [1].
(files you can find there should work with myfaces-core 2.0.x and 2.1.x)

regards,
gerhard

[1] http://people.apache.org/~gpetracek/benchmark/mf-core/

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2011/8/10 Leonardo Uribe <lu...@gmail.com>

> Hi Gerhard
>
> 2011/8/9 Gerhard Petracek <ge...@gmail.com>:
> > hi leo,
> > we don't have control over the performance of custom el-resolvers.
> > the comparator would help but then we are again at the point mentioned by
> > martin.
>
> But precisely that's the point. My theory at first view (and as any
> theory untested yet) is any optimization here will be marginal,
> because it should "assume" some specific EL chain and practically it
> will do the same as the code without use it. A custom el-resolver
> could break the optimization, because it should impose some "contract"
> and the custom one could not preserve it.
>
> > for sure we can do both. to get a first impression, we don't have to
> > prototype all edge cases.
> > e.g. we can test it by just mapping a custom el-resolver (e.g. the owb
> > el-resolver). that doesn't take that much time (if it works at all).
> > however, maybe martin can provide some concrete numbers.
>
> That could help.
>
> regards,
>
> Leonardo Uribe
>
> > 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 Leonardo Uribe <lu...@gmail.com>
> >>
> >> Hi
> >>
> >> 2011/8/9 Gerhard Petracek <ge...@gmail.com>:
> >> > hi leo,
> >> > that's why i asked martin concerning results and he answered that he
> can
> >> > see
> >> > a big difference.
> >> > currently we just think about different approaches. that doesn't mean
> >> > that
> >> > we commit something to the trunk within the next days.
> >> > if we prototype such an improvement, we have to do it e.g. in a branch
> >> > and
> >> > measure the differences (just a real comparison will show the
> difference
> >> > and
> >> > no theoretical discussion).
> >>
> >> Yes, but note a comparison against some ELResolvers without review
> >> them could lead to wrong conclusions. First we need to check if the
> >> current implementation of our ELResolvers runs fast enough and then do
> >> the comparison.
> >>
> >> Anyway I don't understand why try an optimization without know how it
> >> can enhance performance. It sound like a trial and error approach, and
> >> probably it will waste a lot of time and resources that can be saved
> >> with a good analysis.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> > 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 Leonardo Uribe <lu...@gmail.com>
> >> >>
> >> >> Hi
> >> >>
> >> >> I have doubts about if we are really looking on the real source of
> the
> >> >> problem, or if some hack can improve the speed of the code. In theory
> >> >> each EL resolver do a quick-check before do the real work. Thinking
> >> >> about a solution based on the previous comments, I don't see where is
> >> >> the improvement, because after all, we need to do all the steps that
> >> >> are doing the chain right now.
> >> >>
> >> >> I think the trick is check carefully each resolver and what is doing,
> >> >> and enhance that part.  Remember that is "expensive" is not an
> >> >> interation over an array, is the comparisons, lookups to maps or
> other
> >> >> code that is executed over and over.
> >> >>
> >> >> regards,
> >> >>
> >> >> Leonardo Uribe
> >> >>
> >> >> 2011/8/9 Martin Koci <ma...@gmail.com>:
> >> >> > 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 <ge...@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 <ma...@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 <ma...@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.koci@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
> >> >> >> >> >         >
> >> >> >> >> >         >
> >> >> >> >> >         >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>

Re: [core] performance: custom implicit objects

[Leonardo Uribe <lu...@gmail.com>]

Hi Gerhard

2011/8/9 Gerhard Petracek <ge...@gmail.com>:
> hi leo,
> we don't have control over the performance of custom el-resolvers.
> the comparator would help but then we are again at the point mentioned by
> martin.

But precisely that's the point. My theory at first view (and as any
theory untested yet) is any optimization here will be marginal,
because it should "assume" some specific EL chain and practically it
will do the same as the code without use it. A custom el-resolver
could break the optimization, because it should impose some "contract"
and the custom one could not preserve it.

> for sure we can do both. to get a first impression, we don't have to
> prototype all edge cases.
> e.g. we can test it by just mapping a custom el-resolver (e.g. the owb
> el-resolver). that doesn't take that much time (if it works at all).
> however, maybe martin can provide some concrete numbers.

That could help.

regards,

Leonardo Uribe

> 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 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi
>>
>> 2011/8/9 Gerhard Petracek <ge...@gmail.com>:
>> > hi leo,
>> > that's why i asked martin concerning results and he answered that he can
>> > see
>> > a big difference.
>> > currently we just think about different approaches. that doesn't mean
>> > that
>> > we commit something to the trunk within the next days.
>> > if we prototype such an improvement, we have to do it e.g. in a branch
>> > and
>> > measure the differences (just a real comparison will show the difference
>> > and
>> > no theoretical discussion).
>>
>> Yes, but note a comparison against some ELResolvers without review
>> them could lead to wrong conclusions. First we need to check if the
>> current implementation of our ELResolvers runs fast enough and then do
>> the comparison.
>>
>> Anyway I don't understand why try an optimization without know how it
>> can enhance performance. It sound like a trial and error approach, and
>> probably it will waste a lot of time and resources that can be saved
>> with a good analysis.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> > 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 Leonardo Uribe <lu...@gmail.com>
>> >>
>> >> Hi
>> >>
>> >> I have doubts about if we are really looking on the real source of the
>> >> problem, or if some hack can improve the speed of the code. In theory
>> >> each EL resolver do a quick-check before do the real work. Thinking
>> >> about a solution based on the previous comments, I don't see where is
>> >> the improvement, because after all, we need to do all the steps that
>> >> are doing the chain right now.
>> >>
>> >> I think the trick is check carefully each resolver and what is doing,
>> >> and enhance that part.  Remember that is "expensive" is not an
>> >> interation over an array, is the comparisons, lookups to maps or other
>> >> code that is executed over and over.
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> 2011/8/9 Martin Koci <ma...@gmail.com>:
>> >> > 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
>> >> >> >> >         >
>> >> >> >> >         >
>> >> >> >> >         >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >
>> >
>
>

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

hi leo,

we don't have control over the performance of custom el-resolvers.
the comparator would help but then we are again at the point mentioned by
martin.

for sure we can do both. to get a first impression, we don't have to
prototype all edge cases.
e.g. we can test it by just mapping a custom el-resolver (e.g. the owb
el-resolver). that doesn't take that much time (if it works at all).

however, maybe martin can provide some concrete numbers.

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 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> 2011/8/9 Gerhard Petracek <ge...@gmail.com>:
> > hi leo,
> > that's why i asked martin concerning results and he answered that he can
> see
> > a big difference.
> > currently we just think about different approaches. that doesn't mean
> that
> > we commit something to the trunk within the next days.
> > if we prototype such an improvement, we have to do it e.g. in a branch
> and
> > measure the differences (just a real comparison will show the difference
> and
> > no theoretical discussion).
>
> Yes, but note a comparison against some ELResolvers without review
> them could lead to wrong conclusions. First we need to check if the
> current implementation of our ELResolvers runs fast enough and then do
> the comparison.
>
> Anyway I don't understand why try an optimization without know how it
> can enhance performance. It sound like a trial and error approach, and
> probably it will waste a lot of time and resources that can be saved
> with a good analysis.
>
> regards,
>
> Leonardo Uribe
>
> > 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 Leonardo Uribe <lu...@gmail.com>
> >>
> >> Hi
> >>
> >> I have doubts about if we are really looking on the real source of the
> >> problem, or if some hack can improve the speed of the code. In theory
> >> each EL resolver do a quick-check before do the real work. Thinking
> >> about a solution based on the previous comments, I don't see where is
> >> the improvement, because after all, we need to do all the steps that
> >> are doing the chain right now.
> >>
> >> I think the trick is check carefully each resolver and what is doing,
> >> and enhance that part.  Remember that is "expensive" is not an
> >> interation over an array, is the comparisons, lookups to maps or other
> >> code that is executed over and over.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2011/8/9 Martin Koci <ma...@gmail.com>:
> >> > 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
> >> >> >> >         >
> >> >> >> >         >
> >> >> >> >         >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >
> >
>

Re: [core] performance: custom implicit objects

[Leonardo Uribe <lu...@gmail.com>]

Hi

2011/8/9 Gerhard Petracek <ge...@gmail.com>:
> hi leo,
> that's why i asked martin concerning results and he answered that he can see
> a big difference.
> currently we just think about different approaches. that doesn't mean that
> we commit something to the trunk within the next days.
> if we prototype such an improvement, we have to do it e.g. in a branch and
> measure the differences (just a real comparison will show the difference and
> no theoretical discussion).

Yes, but note a comparison against some ELResolvers without review
them could lead to wrong conclusions. First we need to check if the
current implementation of our ELResolvers runs fast enough and then do
the comparison.

Anyway I don't understand why try an optimization without know how it
can enhance performance. It sound like a trial and error approach, and
probably it will waste a lot of time and resources that can be saved
with a good analysis.

regards,

Leonardo Uribe

> 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 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi
>>
>> I have doubts about if we are really looking on the real source of the
>> problem, or if some hack can improve the speed of the code. In theory
>> each EL resolver do a quick-check before do the real work. Thinking
>> about a solution based on the previous comments, I don't see where is
>> the improvement, because after all, we need to do all the steps that
>> are doing the chain right now.
>>
>> I think the trick is check carefully each resolver and what is doing,
>> and enhance that part.  Remember that is "expensive" is not an
>> interation over an array, is the comparisons, lookups to maps or other
>> code that is executed over and over.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/8/9 Martin Koci <ma...@gmail.com>:
>> > 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
>> >> >> >         >
>> >> >> >         >
>> >> >> >         >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>
>

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

hi leo,

that's why i asked martin concerning results and he answered that he can see
a big difference.

currently we just think about different approaches. that doesn't mean that
we commit something to the trunk within the next days.
if we prototype such an improvement, we have to do it e.g. in a branch and
measure the differences (just a real comparison will show the difference and
no theoretical discussion).

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 Leonardo Uribe <lu...@gmail.com>

> Hi
>
> I have doubts about if we are really looking on the real source of the
> problem, or if some hack can improve the speed of the code. In theory
> each EL resolver do a quick-check before do the real work. Thinking
> about a solution based on the previous comments, I don't see where is
> the improvement, because after all, we need to do all the steps that
> are doing the chain right now.
>
> I think the trick is check carefully each resolver and what is doing,
> and enhance that part.  Remember that is "expensive" is not an
> interation over an array, is the comparisons, lookups to maps or other
> code that is executed over and over.
>
> regards,
>
> Leonardo Uribe
>
> 2011/8/9 Martin Koci <ma...@gmail.com>:
> > 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
> >> >> >         >
> >> >> >         >
> >> >> >         >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
>

Re: [core] performance: custom implicit objects

[Leonardo Uribe <lu...@gmail.com>]

Hi

I have doubts about if we are really looking on the real source of the
problem, or if some hack can improve the speed of the code. In theory
each EL resolver do a quick-check before do the real work. Thinking
about a solution based on the previous comments, I don't see where is
the improvement, because after all, we need to do all the steps that
are doing the chain right now.

I think the trick is check carefully each resolver and what is doing,
and enhance that part.  Remember that is "expensive" is not an
interation over an array, is the comparisons, lookups to maps or other
code that is executed over and over.

regards,

Leonardo Uribe

2011/8/9 Martin Koci <ma...@gmail.com>:
> 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
>> >> >         >
>> >> >         >
>> >> >         >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

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 <ma...@gmail.com>

> 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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
> > >> >         >
> > >> >         >
> > >> >         >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
> >
>
>
>

Re: [core] performance: custom implicit objects

[Martin Koci <ma...@gmail.com>]

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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
> >> >         >
> >> >         >
> >> >         >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
> 
> 
> 

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

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 <ja...@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 <ge...@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 <ma...@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 <ma...@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 <ma...@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
>

Re: [core] performance: custom implicit objects

[Jakob Korherr <ja...@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 <ge...@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 <ma...@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 <ma...@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 <ma...@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

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@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 <ma...@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 <ma...@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 <ma...@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
> >         >
> >         >
> >         >
> >
> >
> >
> >
> >
>
>
>

Re: [core] performance: custom implicit objects

[Martin Koci <ma...@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 <ma...@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 <ma...@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
>         >
>         >
>         >
>         
>         
>         
> 
> 

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

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 <ma...@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 <ma...@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
> >
> >
> >
>
>
>

Re: [core] performance: custom implicit objects

[Martin Koci <ma...@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 <ma...@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
>         
> 
> 

Re: [core] performance: custom implicit objects

[Gerhard Petracek <ge...@gmail.com>]

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 <ma...@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
>
>