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

Romain Manni-Bucau rmannibucau at gmail.com
Thu Jan 15 05:27:10 EST 2015


""A valid bean name is a period-separated list of valid EL
identifiers."" explicitely means a bean name is not a valid EL
identifier if it contains a period: all its parts are valid but put
together it is not more valid (as explained in EL spec with the period
meaning BTW).

This pattern is just not usable - I guess it is not used at all BTW:

@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.




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