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 <[email protected]>
> To: [email protected]
> 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 <[email protected]>
> 
> >  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
> >
> >
> >
> >
> >
> 


      

Reply via email to