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