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

Wed Jan 14 08:09:28 EST 2015

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 at redhat.com>:
>> 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 at redhat.com> 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 at redhat.com>:
>>
>> Which EL test?
>>
>> On 14 Jan 2015, at 11:30, Romain Manni-Bucau <rmannibucau at gmail.com> 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 at redhat.com>:
>>
>> No, a Java EE container needs to pass this test.
>>
>> On 14 Jan 2015, at 11:21, Romain Manni-Bucau <rmannibucau at gmail.com> 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 at redhat.com>:
>>
>> 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 at redhat.com> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
>>
>>