[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