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

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