Re: ELContextStore Question
slightly off-topic, but Mark I was wondering if you could explain why we need to call destroyELContextStore from both the WebBeansConfigurationListener and from the end of the RequestContext? Is there some path that would only hit one of these callers?
Re: ELContextStore Question
hi mark, as i see - the ELContextStore is just for dependent beans. @NormalScoped beans aren't affected (see ELContextStore#addDependent). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Mark Struberg strub...@yahoo.de Hi! I don't really understand the ELContextStore which is used in the WebBeansELResolver. It seems to cache all beans which are invoked via EL. So far so good (but the algorithm needs improvement). But what I absolutely not understand is why it releases all those beans at the end of each request. This leads to invoking @PreDestroy to those beans after every EL encapsulation My first bet is that this was an attempt to resolve 6.4.3. Dependent pseudo-scope and Unified EL, isn't? This defines that in a complex EL statement, multiple references to the same @Dependent scoped bean must always get the same Contextual instance of this very bean. And for those @Dependent scoped beans it is also ok to destroy them, because they don't 'hang' on some NormalScoped bean. But we must not treat @NormalScoped beans this very way! wdyt? LieGrue, strub
Re: ELContextStore Question
hi mark, yes - i agree with you! ok - sounds great! i also planned to optimize it today. so i'll just have a look at your improvements. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Mark Struberg strub...@yahoo.de Yes, what did confuse me first was the fact that half of the bean.getScope().equals(Dependent.class) was coded in the ELResolver (the 'get' part), and half of it in ELContextStore (the 'put' part). So the logic per se was just fine. I cleaned it up a bit, added documentation and also added a cache for name resolvements. This speeds up a typical JSF application with lots of EL about 30% :) I hope it's a bit easier to read now. Please let me know if I forgot / misinterpreted something. LieGrue, strub - Original Message From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@openwebbeans.apache.org Sent: Fri, July 23, 2010 10:43:48 AM Subject: Re: ELContextStore Question hi mark, as i see - the ELContextStore is just for dependent beans. @NormalScoped beans aren't affected (see ELContextStore#addDependent). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Mark Struberg strub...@yahoo.de Hi! I don't really understand the ELContextStore which is used in the WebBeansELResolver. It seems to cache all beans which are invoked via EL. So far so good (but the algorithm needs improvement). But what I absolutely not understand is why it releases all those beans at the end of each request. This leads to invoking @PreDestroy to those beans after every EL encapsulation My first bet is that this was an attempt to resolve 6.4.3. Dependent pseudo-scope and Unified EL, isn't? This defines that in a complex EL statement, multiple references to the same @Dependent scoped bean must always get the same Contextual instance of this very bean. And for those @Dependent scoped beans it is also ok to destroy them, because they don't 'hang' on some NormalScoped bean. But we must not treat @NormalScoped beans this very way! wdyt? LieGrue, strub
Re: ELContextStore Question
hi mark, if you cache normal scope beans as well, please just cache the standard scopes. in special cases a cache for all normal scoped beans would cause side-effects. e.g. in case of an immediate destruction or reset of conversations provided by myfaces codi. the same might be true if you end the session manually. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Gerhard Petracek gerhard.petra...@gmail.com hi mark, yes - i agree with you! ok - sounds great! i also planned to optimize it today. so i'll just have a look at your improvements. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Mark Struberg strub...@yahoo.de Yes, what did confuse me first was the fact that half of the bean.getScope().equals(Dependent.class) was coded in the ELResolver (the 'get' part), and half of it in ELContextStore (the 'put' part). So the logic per se was just fine. I cleaned it up a bit, added documentation and also added a cache for name resolvements. This speeds up a typical JSF application with lots of EL about 30% :) I hope it's a bit easier to read now. Please let me know if I forgot / misinterpreted something. LieGrue, strub - Original Message From: Gerhard Petracek gerhard.petra...@gmail.com To: dev@openwebbeans.apache.org Sent: Fri, July 23, 2010 10:43:48 AM Subject: Re: ELContextStore Question hi mark, as i see - the ELContextStore is just for dependent beans. @NormalScoped beans aren't affected (see ELContextStore#addDependent). regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/23 Mark Struberg strub...@yahoo.de Hi! I don't really understand the ELContextStore which is used in the WebBeansELResolver. It seems to cache all beans which are invoked via EL. So far so good (but the algorithm needs improvement). But what I absolutely not understand is why it releases all those beans at the end of each request. This leads to invoking @PreDestroy to those beans after every EL encapsulation My first bet is that this was an attempt to resolve 6.4.3. Dependent pseudo-scope and Unified EL, isn't? This defines that in a complex EL statement, multiple references to the same @Dependent scoped bean must always get the same Contextual instance of this very bean. And for those @Dependent scoped beans it is also ok to destroy them, because they don't 'hang' on some NormalScoped bean. But we must not treat @NormalScoped beans this very way! wdyt? LieGrue, strub
Re: ELContextStore Question
hi mark,
that sounds reasonable.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/23 Mark Struberg strub...@yahoo.de
Hi Gerhard!
I thought about this, but since we are only caching Contextual References
(our
proxies!), this should not make any problems.
Because even if the Contextual Instance behind changes (e.g. a @ViewScoped
bean
points to another instance after the forward), the proxy will simply pickup
the
new instance.
I also thought about returning the Contextual Instance directly, but there
are 2
arguments against this
a) the one you mentioned in your mail. We would need to detect any
'instance
changes' on a page. or cleanup the ELContextStore after a page/tree got
rendered.
b) if you use this bean in a EL method call e.g. #{a.setUser(user)} and a
stores
the User internally, this might be problematic
I'm thinking about introducing a mechanism to better support request scoped
(or
'bigger' scoped) beans via a RequestScopedBeanProxyHandler (like we already
do
for @ApplicationScoped beans). + a property which allows adding of own 3rd
party
scopes.
But I need to profile this first, to see if it's really worth it.
LieGrue,
strub
- Original Message
From: Gerhard Petracek gerhard.petra...@gmail.com
To: dev@openwebbeans.apache.org
Sent: Fri, July 23, 2010 1:10:22 PM
Subject: Re: ELContextStore Question
hi mark,
if you cache normal scope beans as well, please just cache the standard
scopes.
in special cases a cache for all normal scoped beans would cause
side-effects.
e.g. in case of an immediate destruction or reset of conversations
provided
by myfaces codi.
the same might be true if you end the session manually.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/23 Gerhard Petracek gerhard.petra...@gmail.com
hi mark,
yes - i agree with you!
ok - sounds great!
i also planned to optimize it today.
so i'll just have a look at your improvements.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/23 Mark Struberg strub...@yahoo.de
Yes, what did confuse me first was the fact that half of the
bean.getScope().equals(Dependent.class) was coded in the ELResolver
(the
'get'
part), and half of it in ELContextStore (the 'put' part).
So the logic per se was just fine. I cleaned it up a bit, added
documentation
and also added a cache for name resolvements. This speeds up a
typical
JSF
application with lots of EL about 30% :)
I hope it's a bit easier to read now. Please let me know if I forgot
/
misinterpreted something.
LieGrue,
strub
- Original Message
From: Gerhard Petracek gerhard.petra...@gmail.com
To: dev@openwebbeans.apache.org
Sent: Fri, July 23, 2010 10:43:48 AM
Subject: Re: ELContextStore Question
hi mark,
as i see - the ELContextStore is just for dependent beans.
@NormalScoped beans aren't affected (see
ELContextStore#addDependent).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/23 Mark Struberg strub...@yahoo.de
Hi!
I don't really understand the ELContextStore which is used in
the
WebBeansELResolver.
It seems to cache all beans which are invoked via EL. So far so
good
(but
the
algorithm needs improvement).
But what I absolutely not understand is why it releases all
those
beans at
the
end of each request. This leads to invoking @PreDestroy to those
beans
after
every EL encapsulation
My first bet is that this was an attempt to resolve 6.4.3.
Dependent
pseudo-scope and Unified EL, isn't?
This defines that in a complex EL statement, multiple references
to
the
same
@Dependent scoped bean must always get the same Contextual
instance
of this
very
bean. And for those @Dependent scoped beans it is also ok to
destroy
them,
because they don't 'hang' on some NormalScoped bean.
But we must not treat @NormalScoped beans this very way!
wdyt?
LieGrue,
strub
ELContextStore Question
Hi! I don't really understand the ELContextStore which is used in the WebBeansELResolver. It seems to cache all beans which are invoked via EL. So far so good (but the algorithm needs improvement). But what I absolutely not understand is why it releases all those beans at the end of each request. This leads to invoking @PreDestroy to those beans after every EL encapsulation My first bet is that this was an attempt to resolve 6.4.3. Dependent pseudo-scope and Unified EL, isn't? This defines that in a complex EL statement, multiple references to the same @Dependent scoped bean must always get the same Contextual instance of this very bean. And for those @Dependent scoped beans it is also ok to destroy them, because they don't 'hang' on some NormalScoped bean. But we must not treat @NormalScoped beans this very way! wdyt? LieGrue, strub
