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

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