[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:35:51 EST 2015
>> @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.
>>
>>
>>
>> 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