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.
> 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.
Kin-man
>> 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
>>