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

From: Pete Muir <pmuir(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: Martin Kouba <mkouba(a)redhat.com>; Edward Burns <edward.burns(a)oracle.com>; Cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Wednesday, 14 January 2015, 17:03 Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name. > On 14 Jan 2015, at 15:59, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > > Pete, the solution in Weld is a.) breaking other CDI spec paragraphs, Which ones. > b.) not clearly mandated I disagree with this, I think the mandate is clear. The name is specified. > and c.) randomly depending on the ELResolver order. The container must make sure that the ELResolver order is correct. > > > It is just not a wise idea. > > LieGrue, > strub > > > > > ----- Original Message ----- >> From: Pete Muir <pmuir(a)redhat.com&gt; >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> Cc: Martin Kouba <mkouba(a)redhat.com>; Edward Burns <edward.burns(a)oracle.com>; Cdi-dev <cdi-dev(a)lists.jboss.org&gt; >> Sent: Wednesday, 14 January 2015, 16:51 >> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name. >> >> As previously stated I don’t agree with your arguments, and I don’t believe you >> can prove “no one is using it”. >> >> >>> On 14 Jan 2015, at 15:49, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >>> >>> No pete, the current Weld implementation breaks other CDI features! Sample >> with @Named("javax") already given in my other post... >>> >>> >>> It sucks, face it. And no one is using it anyway. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> ________________________________ >>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>> To: Martin Kouba <mkouba(a)redhat.com&gt; >>>> Cc: Edward Burns <edward.burns(a)oracle.com>; Cdi-dev >> <cdi-dev(a)lists.jboss.org&gt; >>>> Sent: Wednesday, 14 January 2015, 13:12 >>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." >> is not valid in an EL name. >>>> >>>> >>>> >>>> I agree with Martin. We *should* fix this situation in the long term, >> which is what I proposed. However in the short term there is no problem with not >> passing a particular test from the EL spec. Additionally this is provably >> implementable as Weld implements this, and many Java EE containers pass. As >> there are no other spec defined beans javax, then we do not conflict with any >> other spec by implementing it this way. >>>> >>>> >>>> >>>>> >>>>> >>>>> On 14 Jan 2015, at 12:10, Martin Kouba <mkouba(a)redhat.com&gt; >> wrote: >>>>> >>>>> Dne 14.1.2015 v 12:43 Romain Manni-Bucau napsal(a): >>>>> >>>>> well there are 2 points: >>>>>> 1) a test should be added for it >>>>>> >>>>> There was a CDI TCK test since 1.1 >> (org.jboss.cdi.tck.tests.context.conversation.LongRunningConversationPropagatedByFacesContextTest). >> It has been modified a week ago (see also CDITCK-462) not to use >> "javax.enterprise.context.conversation.id". >>>>> >>>>> >>>>> 2) test or not being certified means respecting the spec (pdf, >> javadoc >>>>>> + tests themselve) >>>>>> >>>>>> So if there is this test a container can't be certified for >> EL + CDI >>>>>> at the same time >>>>>> >>>>> I don't think it's a problem. An EL TCK test can't >> evaluate "#{javax.enterprise.context.conversation.id}" as an >> illegal expression - it's obviously legal. The problem is >> "javax.enterprise.context.conversation.id" can't be simply used as >> a bean name. If it is, a workaround is needed (see also >> http://lists.jboss.org/pipermail/cdi-dev/2015-January/005989.html). >>>>> >>>>> >>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2015-01-14 12:35 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: >>>>>> >>>>>> Which EL test? >>>>>>> >>>>>>> >>>>>>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau >> <rmannibucau(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>> then it will not pass EL one >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau >>>>>>>> http://www.tomitribe.com >>>>>>>> http://rmannibucau.wordpress.com >>>>>>>> https://github.com/rmannibucau >>>>>>>> >>>>>>>> >>>>>>>> 2015-01-14 12:27 GMT+01:00 Pete Muir >> <pmuir(a)redhat.com&gt;: >>>>>>>> >>>>>>>> No, a Java EE container needs to pass this test. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau >> <rmannibucau(a)gmail.com&gt; wrote: >>>>>>>>>> >>>>>>>>>> so it means a JavaEE container will not pass >> this test but it is not an issue? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau >>>>>>>>>> http://www.tomitribe.com >>>>>>>>>> http://rmannibucau.wordpress.com >>>>>>>>>> https://github.com/rmannibucau >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-01-14 12:20 GMT+01:00 Pete Muir >> <pmuir(a)redhat.com&gt;: >>>>>>>>>> >>>>>>>>>> I don’t think they should be excluded. The spec >> isn’t ambiguous about this, and it is supportable. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 14 Jan 2015, at 11:13, Jozef Hartinger >> <jharting(a)redhat.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>> So for CDI 1.2 the test that tests this >> should not be excluded after all, correct? >>>>>>>>>>>> >>>>>>>>>>>> On 01/14/2015 11:56 AM, Pete Muir >> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 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. >>>> >>>> >>