I think this looks like the right direction. I think the level is just about right (enough power, but pretty simple still). I would suggest a couple more requirements (which I think are implicit in the current design, but I would make them explicit):
* that all these approaches to get beans and add resolvers work against the same "backend" as all the existing apis e.g. if I try to get a bean and EL resolvers etc. are set up in the old style, they will be called or if I add a bean resolver, then resolving a bean using the old APIs will cause the bean resolver to be used
* that access to all the old apis is maintained from the ELManager
On 26 Jul 2011, at 19:09, Kin-man Chung wrote:
> One thing I'd like to work on first is the API for stand alone EL. When EL is used outside of a container, there is a need to make it easier to use. I had the pleasure of discussing this with some of you in the past and we've agreed that it is best to have an API for casual users that mostly want to evaulate EL expressions, and another API for handling the EL engine environment. I attempted to put more details into the APIs, which is summarized in the wiki http://java.net/projects/el-spec/pages/ELProcessorAPI.
>
> Of course details still need to be worked out. For now please tell me, from the architectural point of view, if we are going in the right direction and have the right level of details.
>
> Kin-man