[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 08:44:59 EST 2015
@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