I prefer Option 1.
On 28 Jul 2011, at 18:50, 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.
>
> 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