>>>> On Thu, 8 Jan 2015 08:27:37 +0000 (UTC), Mark Struberg <struberg(a)yahoo.de&gt; said:

>>>> On Fri, 9 Jan 2015 23:41:14 +0000 (UTC), Mark Struberg <struberg(a)yahoo.de&gt; said:

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.

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.

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

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

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

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 <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 <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.

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.

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

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

On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: Well ATM there is no requirement it works

and I'm convinced another (better) solution will be found for coming versions

so I would really avoid to introduce a workaround on which users will not be able to rely.

Also Weld implementation breaks some valid usages of EL (since it is not done for javax only, right?).

Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it. > >> 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. >>>>> >>>>> >>> >

On 14 Jan 2015, at 13:48, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 2015-01-14 14:35 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: > >> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: >> >> Well ATM there is no requirement it works > > There is a requirement that everything in the spec should work, yes. > Well requirement is only due to the test and we can say as much it is a requirement as it is a bug so 0-0 IMO. >> and I'm convinced another >> (better) solution will be found for coming versions > > Yes, but we still have to implement the existing spec as it stands. > >> so I would really >> avoid to introduce a workaround on which users will not be able to >> rely. > > This has been a requirement since version 1.0, a number of years. How has OWB managed to not be compliant with this to date? > That's an open point, I guess it can be linked to the categories used in TCKs - some normal tests are in full profile - but I didnt dig into it to be honest, it can also be it is a new test. >> Also Weld implementation breaks some valid usages of EL (since >> it is not done for javax only, right?). > > For example? > 1) If you already have a custom ELResolver doing it (a spring one randomly ;)) 2) depending the registration ordering of your resolver you can conflict with default BeanResolver >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: >>> I think you need to use the workaround of Weld. It works, and implements the spec as it stands, and means the test will pass. You can argue that the spec is not written in such a way that requires this to work, but you are splitting hairs at this point, and it was the intent of the 1.0 EG that it would work the way Weld implemented it. >>> >>>> 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. >>>>>>> >>>>>>> >>>>> >>> >

This has been a requirement since version 1.0, a number of years. How has OWB managed to not be compliant with this to date?

Yes, but we still have to implement the existing spec as it stands.

Yes, but we still have to implement the existing spec as it stands.

Dne 15.1.2015 v 08:40 Mark Struberg napsal(a): >> >> This has been a requirement since version 1.0, a number of years. How has >> OWB >> managed to not be compliant with this to date? > > > > I quickly checked the logs for the CDI-1.0 tck run and it seems that the > test even passes if #{javax.enterprise.context.conversation.id} resolves to > null. Not sure why though. > > > The other point is that OWB doesn't claim to pass the full TCK but only > the SE parts. This is the same as for Weld. With the CDI container alone you > simply cannot pass those. > > The EE part is being tested when being integrated into an EE server > (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an > additional ELResolver for it? But I honestly doubt it. > > > >> Yes, but we still have to implement the existing spec as it stands. > > I understand that we cannot make sure that nobody ever used this. But it > contradicts other (older) EE specs and the current wording is imo not that > clear that it is really mandatory to support it (as outlined in my other > mail). > > There is also a very easy hack to get this back if a user really wants: > > @Named("javax") > public class ConversationElHelperJavax { > > public ConversationElHelperEnterprise getEnterprise() {..} > > > public class ConversationElHelperEnterprise { > public ConversationElHelperConversation getConversation() > > > } > > and the most inner class just returns the current Conversation instance. > > > Thus a user can totally easily get this behaviour by himself IF he needs > it! Wouldn't be better (from the user point of view) to provide such a bean in OWB? Just for compatibility reasons. Of course, we should also explicitly state that "javax.enterprise.context.conversation" is deprecated and users and encouraged not to use it... Moreover, I think there are more users using "javax.enterprise.context.conversation" than users having a CDI bean with name "javax". > > > LieGrue, > strub > > > > ----- Original Message ----- >> >> From: Pete Muir <pmuir(a)redhat.com&gt; >> To: Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >> Cc: Edward Burns <edward.burns(a)oracle.com>; Cdi-dev >> <cdi-dev(a)lists.jboss.org&gt; >> Sent: Wednesday, 14 January 2015, 14:35 >> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid >> in an EL name. >> >> >>> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >> >> wrote: >>> >>> >>> Well ATM there is no requirement it works >> >> >> There is a requirement that everything in the spec should work, yes. >> >>> and I'm convinced another >>> (better) solution will be found for coming versions >> >> >> Yes, but we still have to implement the existing spec as it stands. >> >>> so I would really >>> avoid to introduce a workaround on which users will not be able to >>> rely. >> >> >> This has been a requirement since version 1.0, a number of years. How has >> OWB >> managed to not be compliant with this to date? >> >>> Also Weld implementation breaks some valid usages of EL (since >>> it is not done for javax only, right?). >> >> >> For example? >> >> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: >>>> >>>> I think you need to use the workaround of Weld. It works, and >> >> implements the spec as it stands, and means the test will pass. You can >> argue >> that the spec is not written in such a way that requires this to work, >> but you >> are splitting hairs at this point, and it was the intent of the 1.0 EG >> that it >> would work the way Weld implemented it. >>>> >>>> >>>>> 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. >>>>>>>> >>>>>>>> >>>>>> >>>> >> >> >> _______________________________________________ >> 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. >

From: Jozef Hartinger <jharting(a)redhat.com&gt; To: Romain Manni-Bucau <rmannibucau(a)gmail.com>; 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: Thursday, 15 January 2015, 10:46 Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name. After looking into the spec again it became apparent to me that this is not an issue of a poorly chosen name for a built-in bean as it may look like at the first glance. Instead, CDI seems to define bean names on top of EL. It says: "A valid bean name is a period-separated list of valid EL identifiers." It even goes further and says: "The following strings are valid bean names: com.acme.settings" This means that a bean name *does not have to be a valid EL name*. It has to be a period-separated list of valid EL identifiers i.e. a valid EL expression. This implies that a CDI implementation needs to have a special mechanism for resolving a bean from an EL expression which recognizes the concept of bean names built on top of EL names (like Weld does). On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote: > -1 to provide a bean "javax" it is worse than hacking EL to support it > since it also impacts other cases. > > That said as Mark showed not having it is not a blocker for a user so > why not just adding the "SHOULD support for EL" since spec(s) dont > proove it is mandatory since EE 6. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba(a)redhat.com&gt;: >> Dne 15.1.2015 v 08:40 Mark Struberg napsal(a): >>>> This has been a requirement since version 1.0, a number of years. How has >>>> OWB >>>> managed to not be compliant with this to date? >>> >>> >>> I quickly checked the logs for the CDI-1.0 tck run and it seems that the >>> test even passes if #{javax.enterprise.context.conversation.id} resolves to >>> null. Not sure why though. >>> >>> >>> The other point is that OWB doesn't claim to pass the full TCK but only >>> the SE parts. This is the same as for Weld. With the CDI container alone you >>> simply cannot pass those. >>> >>> The EE part is being tested when being integrated into an EE server >>> (WebSphere, SAP, TomEE, Geronimo,..) Those servers probably have an >>> additional ELResolver for it? But I honestly doubt it. >>> >>> >>> >>>> Yes, but we still have to implement the existing spec as it stands. >>> I understand that we cannot make sure that nobody ever used this. But it >>> contradicts other (older) EE specs and the current wording is imo not that >>> clear that it is really mandatory to support it (as outlined in my other >>> mail). >>> >>> There is also a very easy hack to get this back if a user really wants: >>> >>> @Named("javax") >>> public class ConversationElHelperJavax { >>> >>> public ConversationElHelperEnterprise getEnterprise() {..} >>> >>> >>> public class ConversationElHelperEnterprise { >>> public ConversationElHelperConversation getConversation() >>> >>> >>> } >>> >>> and the most inner class just returns the current Conversation instance. >>> >>> >>> Thus a user can totally easily get this behaviour by himself IF he needs >>> it! >> >> Wouldn't be better (from the user point of view) to provide such a bean in >> OWB? Just for compatibility reasons. Of course, we should also explicitly >> state that "javax.enterprise.context.conversation" is deprecated and users >> and encouraged not to use it... >> >> Moreover, I think there are more users using >> "javax.enterprise.context.conversation" than users having a CDI bean with >> name "javax". >> >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>> To: Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>>> Cc: Edward Burns <edward.burns(a)oracle.com>; Cdi-dev >>>> <cdi-dev(a)lists.jboss.org&gt; >>>> Sent: Wednesday, 14 January 2015, 14:35 >>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid >>>> in an EL name. >>>> >>>> >>>>> On 14 Jan 2015, at 13:31, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>>> wrote: >>>>> >>>>> Well ATM there is no requirement it works >>>> >>>> There is a requirement that everything in the spec should work, yes. >>>> >>>>> and I'm convinced another >>>>> (better) solution will be found for coming versions >>>> >>>> Yes, but we still have to implement the existing spec as it stands. >>>> >>>>> so I would really >>>>> avoid to introduce a workaround on which users will not be able to >>>>> rely. >>>> >>>> This has been a requirement since version 1.0, a number of years. How has >>>> OWB >>>> managed to not be compliant with this to date? >>>> >>>>> Also Weld implementation breaks some valid usages of EL (since >>>>> it is not done for javax only, right?). >>>> >>>> For example? >>>> >>>> >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau >>>>> http://www.tomitribe.com >>>>> http://rmannibucau.wordpress.com >>>>> https://github.com/rmannibucau >>>>> >>>>> >>>>> 2015-01-14 14:28 GMT+01:00 Pete Muir <pmuir(a)redhat.com&gt;: >>>>>> I think you need to use the workaround of Weld. It works, and >>>> implements the spec as it stands, and means the test will pass. You can >>>> argue >>>> that the spec is not written in such a way that requires this to work, >>>> but you >>>> are splitting hairs at this point, and it was the intent of the 1.0 EG >>>> that it >>>> would work the way Weld implemented it. >>>>>> >>>>>>> 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. >>>>>>>>>> >>>>>>>>>> >>>> >>>> _______________________________________________ >>>> 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.

________________________________ 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 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;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 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;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 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;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 &gt;&gt;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.

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

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

I hope I can be allowed to inject myself into this conversation. I can see a little emotional escalation creeping in here, so let's leave that between the keyboard and the chair. Now, some comments below: >>>>> On Wed, 14 Jan 2015 12:12:57 +0000, Pete Muir <pmuir(a)redhat.com&gt; said: PM> I agree with Martin. We *should* fix this situation in the long PM> term, which is what I proposed. However in the short term there is PM> no problem with not passing a particular test from the EL PM> spec. Additionally this is provably implementable as Weld implements PM> this, and many Java EE containers pass. As there are no other spec PM> defined beans javax, then we do not conflict with any other spec by PM> implementing it this way. >>>>> On Wed, 14 Jan 2015 15:52:17 +0000 (UTC), Mark Struberg <struberg(a)yahoo.de&gt; said: MS> @Named("javax") MS> public class MyService {..} >>>>> On Wed, 14 Jan 2015 16:22:31 +0000 (UTC), Mark Struberg <struberg(a)yahoo.de&gt; said: MS> is a perfectly valid CDI bean. Still it would be broken with Weld. >>>>> On Wed, 14 Jan 2015 16:19:31 +0000 (UTC), Mark Struberg <struberg(a)yahoo.de&gt; said: MS> 6.7.5 just defines Spec> "The container provides a built-in bean with bean type Spec> Conversation, scope @RequestScoped, and qualifier @Default, named Spec> javax.enterprise.context.conversation." MS> It doesn't state that the bean must be available under MS> #{javax.enterprise.context.conversation} to the EL. This is simply MS> just implicated by the bean.name rules. MS> 3.) paragraph 2.6 Bean names: MS> It makes a bean visible to EL. BUT read the specified paragraph really carefula! Spec> "A bean may have a bean name. A bean with a name may be referred Spec> to by its name in Unified EL expressions. A valid bean name is a Spec> period-separated list of valid EL identifiers. MS> The important part is "list of _VALID_ EL identifiers" MS> What does this paragraph mean at all? MS> Does this mean that #{javax} is possible as is #{enterprise}, MS> #{context} and #{conversation}? Because all those are valid EL MS> identifiers, wheras the combined string is NOT a valid EL MS> identifier. MS> If not and we go for your interpretation then we would also need to MS> support code like MS> @Named("oh.uh.some.other.weird.el.name"} MS> public class TotallyNonsenseService MS> You can turn this as you like. It simply makes no sense at all to MS> support it as EL name. MS> But there is a third option: This is just no valid EL identifier and MS> thus it is not exposed to EL but only to mechanism 1.) (@Inject MS> @Named) and 2.) (getBeans(String)). Along the line propopsed by Mark, the CDI spec section 6.7.5 could add some text to this effect, For the purposes of exposing the conversation to EL, the conversation is exposed via the EL name "javax_enterprise_context_Conversation". MS> And then break all applications which have a @Named("javax") public MS> class MyBean? It's simply not an option imo. It breaks lots of MS> other specs and features. This is an XOR situation. I agree we can't do that. Instead we could just add some text that states that there is no requirement for "javax.enterprise.context.conversation" to be exposed as an EL name. Would that work? Ed -- | edward.burns(a)oracle.com | office: +1 407 458 0017 | 36 days til DevNexus 2015 | 46 days til JavaLand 2015 | 56 days til CONFESS 2015

On 14 Jan 2015, at 15:46, Mark Struberg <struberg(a)yahoo.de&gt; wrote: The spec only says that the Bean must have this name. All the rest is some 3-rd level 'implicit' arguing. The spec does NOT say that the EL "javax...." must give you a Conversation... LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: Jozef Hartinger <jharting(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, 12:20 > Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name. > > 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. >

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.

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.

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

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

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

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

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&gt;: > >> 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&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. >>>>>>>> >>>>>>>>

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.

From: Jozef Hartinger <jharting(a)redhat.com&gt; To: Mark Struberg <struberg(a)yahoo.de>; Cdi-dev <cdi-dev(a)lists.jboss.org&gt; Cc: Edward Burns <edward.burns(a)oracle.com&gt; Sent: Wednesday, 14 January 2015, 10:54 Subject: Re: [cdi-dev] Fw: Answer from EL spec lead: no, "." is not valid in an EL name. 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.