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

On Friday, 16 January 2015, 8:11, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > 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. >>>>>>>>