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

Romain Manni-Bucau rmannibucau at gmail.com
Wed Jan 14 08:13:35 EST 2015


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 at redhat.com>:
> 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.
>>>
>>>
>



More information about the cdi-dev mailing list