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

""A valid bean name is a period-separated list of valid EL identifiers."" explicitely means a bean name is not a valid EL identifier if it contains a period: all its parts are valid but put together it is not more valid (as explained in EL spec with the period meaning BTW).

This pattern is just not usable - I guess it is not used at all BTW: @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.

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