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

Hmm Does it mean CDI cant add javax.enterprise.xxx bean? Or even other specs cant add javax.xxx beans? Le 16 janv. 2015 08:10, "Jozef Hartinger" <jharting(a)redhat.com <mailto:jharting@redhat.com>> a écrit : 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 <mailto:jharting@redhat.com>>: 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 <mailto:jharting@redhat.com>>: 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 <mailto:jharting@redhat.com>> 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 <mailto:pmuir@redhat.com>> To: Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> Cc: Cdi-dev <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>; Edward Burns <edward.burns(a)oracle.com <mailto:edward.burns@oracle.com>> 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 <mailto:rmannibucau@gmail.com>> 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 <mailto:jharting@redhat.com>>: 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 <mailto:edward.burns@oracle.com>> 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 <mailto:edward.burns@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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.