Hi folks!
I'll give it a try today too!
LieGrue,
strub
--- On Wed, 8/10/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:
From: Gerhard Petracek gerhard.petra...@gmail.com
Subject: Re: [core] performance: custom implicit objects
To: MyFaces Development dev@myfaces.apache.org
Date
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
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
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
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
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
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
Hi
2011/8/9 Gerhard Petracek gerhard.petra...@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.
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
Hi Gerhard
2011/8/9 Gerhard Petracek gerhard.petra...@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
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
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.
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
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
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
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
16 matches
Mail list logo
