My only concern is in the case of JSP container. Giving a way to alter
the function mapper might give a way to override the container
instantiated FunctionMapper.
In case we need a setter, there should be a way to validate saying the
Web application cannot alter the FunctionMapper.
Ramesh
On 8/3/2011 1:18 AM, Kin-man Chung wrote:
> While implementing ELProcessor and ELManager, I discovered some
> idiosyncrasies with ELContext and FunctionMapper. In FunctionMapper,
> while there is a getter for the function map, there is no setter. The
> same in ELContext for ELResolver. I understand the orginal desinger's
> desire to not allow changes to these instances after the initial
> construction, presumably to allow optimizations in expression evaluations.
>
> Personally, I have not seen any implementation of the EL that can take
> advantage of this to do useful optimizations. Also, that philosophy
> seems to go against our current design for stand-alone EL, which allows
> ELResolvers and functions to be added anytime. The expectation for
> stand-alone EL is that it will be used in a more dynamic environments.
>
> Therefore, I am proposing adding a setter for functions in the
> FunctionMapper. Curiously, there is already a setter for variables in
> VariableMapper. I think I can work around the lack of a setter for
> ELResovers in ELContext, and leave it alone for now.
>
> If there are objections to this, please let me know.
>
> Kin-man
>