[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.

Jozef Hartinger jharting at redhat.com
Thu Jan 15 06:59:00 EST 2015


On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>> lead to conflicts and that's things I saw several times in spring apps
>>> which are clearly not possible using CDI + EL properly.
>> Yes and these conflicts are handled by the spec. See 5.3.1
>>
> Hmm not sure. If enriched is a property of the first bean then spec
> doesn't help.
The spec deals with exactly these types of cases in 5.3.1
>
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x is
>>>>> the
>>>>> bean name of the other bean" will not be a problem.
>>>>>
>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>> ELResolver. That is something totally different.
>>>> Mark, please read the e-mail again. I am not saying there are two beans
>>>> named "javax". I am saying there are two beans with the following names:
>>>>
>>>> - javax.enterprise.context.conversation (the built-in one)
>>>> - javax (Marks's bean)
>>>>
>>>> where the former one is in form x.y where y is a valid bean name:
>>>> (javax) . (enterprise.context.conversation)
>>>>
>>>> and thus since javax is both x above and a bean name of Mark's bean, this
>>>> results in an exception.
>>>>
>>>>
>>>>> Thus the rest of your argumentation chain is also invalid.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>> <jharting at redhat.com> wrote:
>>>>>>> T he @Named("javax") argument is not valid. The spec says:
>>>>>> Suppose two beans are both available for injection in a certain war,
>>>>>> and
>>>>>> either:
>>>>>> - the two beans have the same bean name and the name is not resolvable,
>>>>>> or
>>>>>> - the bean name of one bean is of the form x.y, where y is a valid bean
>>>>>> name, and x is the bean
>>>>>> name of the other bean,
>>>>>> the container automatically detects the problem and treats it as a
>>>>>> deployment problem.
>>>>>>
>>>>>> So we have two beans:
>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>> - javax (Marks's bean)
>>>>>>
>>>>>> now:
>>>>>>
>>>>>> 1) the bean name of one bean is of the form x.y, where y is a valid
>>>>>> bean
>>>>>> name - that is javax.enterprise.context.conversation
>>>>>> x = javax
>>>>>> y = enterprise.context.conversation
>>>>>> 2) and x is the bean name of the other bean - same as the name of
>>>>>> Mark's
>>>>>> @Named("javax") bean
>>>>>> 3) the container automatically detects the problem and treats it as a
>>>>>> deployment problem
>>>>>>
>>>>>> Therefore, a bean named @Named("javax") will cause a deployment
>>>>>> problem
>>>>>> no matter whether it is actually available via EL or not.
>>>>>>
>>>>>> To summarize, the spec already anticipates the problem and forbids this
>>>>>> case explicitly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 01/14/2015 04:45 PM, Mark Struberg wrote:
>>>>>>>     And then break all applications which have a @Named("javax")
>>>>>> public class MyBean?
>>>>>>>     It's simply not an option imo. It breaks lots of other specs and
>>>>>> features. This is an XOR situation.
>>>>>>>
>>>>>>>     LieGrue,
>>>>>>>     strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     ----- Original Message -----
>>>>>>>>     From: Pete Muir <pmuir at redhat.com>
>>>>>>>>     To: Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>>>>>     Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns
>>>>>> <edward.burns at oracle.com>
>>>>>>>>     Sent: Wednesday, 14 January 2015, 11:56
>>>>>>>>     Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "."
>>>>>> is not valid in an EL name.
>>>>>>>>     We need to go for both (A) and (B).
>>>>>>>>
>>>>>>>>     We would need to deprecate the existing name before we can allow
>>>>>>>> it
>>>>>>>> to
>>>>>> not be
>>>>>>>>     supported. This means CDI 3. So I would suggest we deprecate it in
>>>>>>>> 2,
>>>>>> add an
>>>>>>>>     alternative that can be used, and then consider removing it in CDI
>>>>>>>> 3.
>>>>>> In the
>>>>>>>>     meantime for CDI 2, we will need to improve the TCK to check this
>>>>>>>> more
>>>>>>>>     carefully.
>>>>>>>>
>>>>>>>>>       On 14 Jan 2015, at 10:09, Romain Manni-Bucau
>>>>>> <rmannibucau at gmail.com>
>>>>>>>>     wrote:
>>>>>>>>>       +1 for B (IMO it is not used that much)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       Romain Manni-Bucau
>>>>>>>>>       @rmannibucau
>>>>>>>>>      http://www.tomitribe.com
>>>>>>>>>      http://rmannibucau.wordpress.com
>>>>>>>>>      https://github.com/rmannibucau
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       2015-01-14 10:54 GMT+01:00 Jozef Hartinger
>>>>>> <jharting at redhat.com>:
>>>>>>>>>>       I think further action is needed on this. Now that it has
>>>>>> been
>>>>>>>>     confirmed
>>>>>>>>>>       that "javax.enterprise.context.conversation" itself
>>>>>> is not a
>>>>>>>>     valid EL
>>>>>>>>>>       name we should either:
>>>>>>>>>>
>>>>>>>>>>       A) Require all CDI implementations to adapt the
>>>>>> property-based approach
>>>>>>>>>>       which allows this to be implemented portably (as Weld does)
>>>>>>>>>>       B) Declare publicly that although the CDI spec declares the
>>>>>> given name,
>>>>>>>>>>       it is a bug and applications should not use the name. (What
>>>>>> about
>>>>>>>>>>       compatibility with existing applications?)
>>>>>>>>>>
>>>>>>>>>>       Jozef
>>>>>>>>>>
>>>>>>>>>>       On 01/08/2015 09:27 AM, Mark Struberg wrote:
>>>>>>>>>>>       Dear CDI fellows!
>>>>>>>>>>>
>>>>>>>>>>>       I've received an answer regarding our EL question
>>>>>> from the EL
>>>>>>>>     Spec Lead.
>>>>>>>>>>>       Ed, thanks for helping us!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>       LieGrue,
>>>>>>>>>>>       strub
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>       On Tuesday, 6 January 2015, 23:14, Edward Burns
>>>>>>>>     <edward.burns at oracle.com> wrote:
>>>>>>>>>>>>>       Hello Mark,
>>>>>>>>>>>>       To close this out, no, "." is not valid in
>>>>>> an EL
>>>>>>>>     name.  An EL name
>>>>>>>>>>>>       must
>>>>>>>>>>>>       be a java identifier.  I'm told this was
>>>>>> discussed by Pete
>>>>>>>>     a long time
>>>>>>>>>>>>       ago in the EL 3.0 EG.
>>>>>>>>>>>>
>>>>>>>>>>>>       Ed
>>>>>>>>>>>>
>>>>>>>>>>>>       --
>>>>>>>>>>>>       | edward.burns at oracle.com | office: +1 407 458 0017
>>>>>>>>>>>>       | 42 days til DevNexus 2015
>>>>>>>>>>>>       | 52 days til JavaLand 2015
>>>>>>>>>>>>       | 62 days til CONFESS 2015
>>>>>>>>>>>>
>>>>>>>>>>>       _______________________________________________
>>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>>
>>>>>>>>>>>       Note that for all code provided on this list, the
>>>>>> provider licenses
>>>>>>>>     the code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>>>       _______________________________________________
>>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>
>>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>> licenses the
>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>>>       _______________________________________________
>>>>>>>>>       cdi-dev mailing list
>>>>>>>>>      cdi-dev at lists.jboss.org
>>>>>>>>>      https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>
>>>>>>>>>       Note that for all code provided on this list, the provider
>>>>>> licenses the
>>>>>>>>     code under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     cdi-dev mailing list
>>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>>     Note that for all code provided on this list, the provider
>>>>>>>> licenses
>>>>>>>> the
>>>>>> code
>>>>>>>>     under the Apache License, Version 2
>>>>>>>>     (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>>>>>>>> ideas
>>>>>> provided
>>>>>>>>     on this list, the provider waives all patent and other
>>>>>>>> intellectual
>>>>>> property
>>>>>>>>     rights inherent in such information.
>>>>>>>>
>>>>>>>     _______________________________________________
>>>>>>>     cdi-dev mailing list
>>>>>>>     cdi-dev at lists.jboss.org
>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>>>     Note that for all code provided on this list, the provider licenses
>>>>>>> the
>>>>>> code under the Apache License, Version 2
>>>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>> provided
>>>>>> on this list, the provider waives all patent and other intellectual
>>>>>> property
>>>>>> rights inherent in such information.
>>>>>>



More information about the cdi-dev mailing list