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

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. >>>>>>