Sounds good to me.
Sent from my iPhone
On Aug 23, 2011, at 9:27, Pete Muir <pmuir(a)redhat.com> wrote:
Hi all,
On the JSR-341 (EL.next) we've been discussing making bean namespacing a first class
feature.
Currently the proposal on the table from JSR-341 is that the built in conversation bean
would be referenced by #{N(javax.enterprise.context).conversation}. This is obviously a
deviation from the syntax that CDI 1.0 has used (#{javax.enterprise.context.conversation})
but does remove the ambiguity between property/method access and namespacing that is
inherent in the CDI 1.0 option.
I would propose that the CDI 1.1 spec is updated to recommend this approach, and that the
old approach is deprecated for CDI 1.1 (but still required to work). We can then address
in CDI 1.1.next whether we want to remove the 1.0 approach, or keep it for backwards
compatibility.
Below is the thread on which we discussed this, including some ideas on how to implement
the old approach on top of the new EL namespace support.
Any concerns?
Pete
Begin forwarded message:
> From: Kin-man Chung <kinman.chung(a)oracle.com>
> Date: 12 August 2011 19:24:16 GMT+01:00
> To: jsr341-experts(a)el-spec.java.net
> Subject: [jsr341-experts] Re: Bean names with namespace
> Reply-To: jsr341-experts(a)el-spec.java.net
>
> On 08/12/11 10:29, Pete Muir wrote:
>> Sorry for the late reply.
>>
>> On 9 Aug 2011, at 21:25, Kin-man Chung wrote:
>>
>>
>>> On 08/09/11 12:03, Pete Muir wrote:
>>>
>>>> On 9 Aug 2011, at 18:02, Kin-man Chung wrote:
>>>>
>>>>
>>>>
>>>>> I recall that it is a CDI requirement that bean names can have
namespaces, such as "org.goofy.configs". Pete, is this still the case?
>>>>>
>>>>>
>>>> Yes. This is in the CDI spec, so can't be removed right away, we need
to support this for at least the next revision.
>>>>
>>>>
>>>>
>>> I am curious about how it got in the CDI spec in the first place? It is just
a little strange that CDI can write into its spec about some functionalities in another
spec that is currently not supported, to say the least.
>>>
>> Sure. CDI doesn't require UEL to support namespaced beans generally, however
it does require that:
>>
>> * CDI beans can have names which include namespaces as above
>> * CDI beans with names are resolvable by UEL
>>
>> So I don't *think* CDI is specifying a UEL feature, but simply specifying
it's own features and integrations.
>>
>>
> Thanks for clarifying this.
>
> Still, if UEL was consulted before this was put in the CDI spec, it would have been
apparent that it's not a good idea to introduce such ambiguities, and that another
syntax would have been used. Of course I understand that UEL has not been active for a
long time, to say the least, and CDI probably just want to move forward. :-)
>
>>>
>>>>> Are there any other things that EL needs to do, other than the
ability to parse and evaluates it?
>>>>>
>>>>>
>>>> No.
>>>>
>>>>
>>>>
>>>>> Since names that contains a "." creates ambiguities are
parse time, we'll need to resolve it. I propose that we introduce another syntax
notation for it, like what we did for static fields. For instance, we can write
>>>>>
>>>>> #{N(org.goofy.configs).memSize}.
>>>>>
>>>>> to denote the bean org.goofy.configs with the property memSize. What
do you think?
>>>>>
>>>>>
>>>> This wouldn't work for CDI due to backwards compatibility.
>>>>
>>>>
>>>>
>>> What backwards compatibility? It is not working currently! Did you really
got it to work with EL 2.2? How?
>>>
>> Yes it works with UEL 2.2. As we know at deployment time all the bean names,
including namespaces, we can create synthetic objects for each node in the namespace
hierarchy needed. For example we would create an "org" object, with a
"goofy" child object (and perhaps a "jboss" child object were
org.jboss.plmuir.Foo a bean we have as well). When "org" is passed to our
namespace EL resolver, we return this org synthetic object. This is then passed in as the
base when "goofy" is the property to resolve, and we return the Goofy object
(and so on). If we don't have a namespace object, of course we return null.
>>
>> Then, in our bean resolver, if the base is a namespace object, we can cast to it,
and simply call a method on it to retrieve the fully-qualified namespace, concatenate the
current property name, and do a bean lookup.
>>
>>
>>> What I like about the N() notation is that it is easy on the parser as well
as on the user. It provides a visual indication about what the expression does. In
general, it is just not a good language design to contain ambiguities that cannot be
easily resolved.
>>>
>> Understood.
>>
>>
>>>
>>>> Instead (or as well?), could we offer a registerNamespace() method
(similar to how we are handling imports)? Then EL will have a static list of namespaces
that an (optional?) namespace resolver could resolve against before other resolvers are
used. CDI knows namespaces at startup so could register all it needs.
>>>>
>>>> WDYT?
>>>>
>>> If we have to support it without any syntax aid, we'll need to have
something like registerNamespace(). I am not sure how and when the information can be
best used. Ideally, we'd like to be able to recognize the namespaces early, at parse
time, so that we don't need to change how it works at evaluation, so ELResolvers may
not be the right solution. Even at the parse time, it'll require either a deep
look-ahead or backtracking. Also, a simple typo can produce errors that are hard to track
down.
>>>
>>> Can CDI deprecate the current namespace support in favor of the N()
notation?
>>>
>> Yes, I can make it "optional" in 1.1 I guess, introduce the N()
notation and then we can remove it in CDI 1.1+1.
>>
>>
> Can you make sure that CDI EGs are OK with this? Thanks.
>
>> I'm not wedded to the syntax, just looking for the best solution all around.
>>
>>
> I also don't like having to introduce another reserved word. But since we have
already introduced T(), a N() is not too bad. Of course if you have other ideas,
we'll be glad to consider them.
>
>>> Can CDI implementation provides a tools to turn #{org.goofy.configs.memSize}
into #{N(org.goofy.configs).memSize}?
>>>
>> I guess, because we know the namespaces up front, we can simply check if
org.goofy.configs is a registered namespace, and if it is, rewrite the EL expression. Does
that sound reasonable?
> Yes, it is. Of course this is just a suggestion for a way to implement namespace in
CDI, taking advantage of the new N() syntax in EL, so that the complicated hack with
ELResolvers would not necessary.
>
> Thanks. I am really glad that we've arrived at a solution acceptable to all of
us! :-)
>
> Kin-man
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev