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

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