On 7/28/2011 11:20 PM, Kin-man Chung wrote:
> Going over the scenarios of how ELProcessor can be used, I realize
> that we need to discuss the scope and life span of an ELProcessor.
> Since ELProcessor is customizable, each user would need to have her
> own version. Moreover, I have also realized that an ELResolver is not
> thread safe, so we cannot have an instance of the default ELResolver
> that is shared by all threads or users.
ELResolver can be shared across threads right? Do you want to say that
ELContext is not thread safe? ELContext is not thread safe because it
has isResolved() attribute.
>
> Therefore getting an instance of ELProcessor (with it an ELManager,
> ELContext and ELResolver) from ExpressionFactory does not sound right
> anymore. I think it would be simpler if we just have concrete (i.e.
> non abstract) classes for them and use "new" to construct them, like
>
> Option 1
> ELManager mgr = new ELManager(new StandardELContext());
> ELProcessor el = new ELProcessor(mgr);
> el.getValue("#{...});
>
> Here StandardELContext is the default ELContext that continas a
> default ELResolver and FunctionMapper etc.
>
> There would be instances of theses objects in each of the thread, with
> no sharing among users or threads. All these objects are quite small,
> so it would not be too costly to construct them.
>
> Alternately, we can have a sharable ELProcessor and ELManager but
> still need to plug into a ELContext for each thread, like
>
> Option 2:
> @Inject // or use ExpressionFactory
> ELProcessor el;
> el.getELManager().setELContext(new StandardELContext());
> el.getValue("#{...});
>
> What do you think? Are there better ideas?
>
> Kin-man
>
How about ELManager having the ELContext class.And while creating the
ELProcessor, ELManager will create ELContext, invoke ELContextListener
if any initialization is required.