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

On 14 Jan 2015, at 13:13, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: well issue is when you activate EL + CDI, if you respect both specs #{javax.enterprise.context.conversation.id} should fail - agree we can always use the *workaround* of Weld but this is actually not mandated by any spec excepted this test which was IMO an interpolation. That's why i think this test shouldnt be kept even for 1.x versions. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-14 14:09 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: > Dne 14.1.2015 v 13:42 Romain Manni-Bucau napsal(a): >> >> If "there is no problem with not passing a particular test from the EL >> spec" then there is no problem with not passing a particular test from >> the CDI spec at EE level which seems wrong to me. >> >> Globally I'd just remove this test and keep it in Weld vendor specific >> features. >> >> @martin: my 1) was for EL spec not CDI. >> >> About 2 "#{javax.enterprise.context.conversation.id}" is legal if id >> is a property of conversation which is a property of context which is >> a property of enterprise which is a property of javax which is clearly >> not what is desired and opposed to what is in the CDI spec. > > > Sure. But EL cannot test this. From it's point of view the > "#{javax.enterprise.context.conversation.id}" expression is ok. From CDI > point of view the name is wrong and cannot be used as it is... > > >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-14 13:12 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: >>> >>> 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. >>> >>> >