On 07/28/11 02:51, Pete Muir wrote:
> On 27 Jul 2011, at 23:17, Kin-man Chung wrote:
>
>
>> On 07/27/11 06:18, Ramesh wrote:
>>
>>> Hi All,
>>>
>>> I am Ramesh PVK, my java.net id is rameshpvk. I live in Hyderabad, India. I work on Pramati App Sever, and have implemented Servlet 2.5 and JSP 2.1 in Pramati. I am also working on Pramati NIO based Web Load balancer. I am also part of Servlet 3.1 EG.
>>>
>>> I too agree in having a simple EL API which can be used easily, where the new API uses the older API in background(instead having two completely independent API's).
>>>
>>>
>> Maybe it was clear from the writeup or the javadocs. The stand alone api IS build on the existing EL api. They are not meant to be independent.
>>
> I would propose adding an introductory note to this effect, I think it will clear up any confusion.
>
>
Done.
Kin-man
>>
>>> Thanks,
>>>
>>>
>>> On 7/27/2011 4:40 PM, Pete Muir wrote:
>>>
>>>> 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
>>>>
>>>>
>> In the current api (I won't say old yet), the EL environment is implicit in the ELContext used, which is maintained by the container. There is no facility in the EL spec to help EL users to create and modify ELContext (and therefore ELResolver). ELManager is proposed to do this.
>>
>> However, I now realize that we need to allow an ELContext that was created by the container be plugged into ELManager so that it becomes the ELContext used by the ELManager. I have therefore make modifications to the ELManager to add a setter for ELContext. (See http://java.net/projects/el-spec/pages/ELProcessorAPI) Then ELResolvers added in ELManager will be effective in the container managed ELContext.
>>
>> I also added a setter to ExpressionFactory, because we may want to make the ExpressionFacotory pluggable.
>>
>> I don't know we'll need to put a restriction on when (or where) they can be made pluggable. The JSP spec has some restrictions on when an ELResolver can be added, for optimizations that presumably cannot be done if ELResolvers are allowed to be added at will.
>>
> Sounds good.
>
>