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

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.