[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Jozef Hartinger
jharting at redhat.com
Fri Jan 16 02:10:50 EST 2015
OK, the relevant part goes:
"If 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."
Let's have:
@Named("team1.superBean.enriched") class Bean1
@Named("team1.superBean") class Bean2
Now
1) "If the bean name of one bean is of the form x.y"
We can match the "x.y" pattern on Bean1's name as:
(team1.superBean) . (enriched)
thus:
x = team1.superBean
y = enriched
2) "where y is a valid bean name"
"enriched" is indeed a valid bean name
3) "and x is the bean name of the other bean"
x ("team1.superBean") is at the same time the name of Bean2
4) Therefore, "the container automatically detects the problem and
treats it as a deployment problem".
Therefore, this scenario does not become a conflict at runtime.
HTH,
Jozef
On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
> @Jozef: can you quote it please - sorry if it is obvious but I dont
> see it in 5.3.1, I look 1.2 version BTW. It only deals with names
> where or CDI where here we conflict between resolvers.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>> 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