[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Jozef Hartinger
jharting at redhat.com
Thu Jan 15 05:33:05 EST 2015
On 01/15/2015 11:27 AM, Romain Manni-Bucau wrote:
> ""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).
Yes, a bean name is not necessarily a valid EL identifier. It however is
a valid EL expression.
>
> 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.
Yes and these conflicts are handled by the spec. See 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