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

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