Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.

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(a)redhat.com&gt;: > >> 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(a)redhat.com&gt;: >>>>> >>>>>> 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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>>>>>>>> To: Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>>>>>>>>> Cc: Cdi-dev <cdi-dev(a)lists.jboss.org>; Edward Burns >>>>>>>>>> >>>>>>>>> <edward.burns(a)oracle.com&gt; >>>>>>>> >>>>>>>>> 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(a)gmail.com&gt; >>>>>>>> >>>>>>>>> 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(a)redhat.com&gt;: >>>>>>>> >>>>>>>>> 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(a)oracle.com&gt; 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(a)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(a)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(a)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(a)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(a)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(a)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. >>>>>>>> >>>>>>>>