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

Pete Muir pmuir at redhat.com
Wed Jan 14 11:03:01 EST 2015


> On 14 Jan 2015, at 15:59, Mark Struberg <struberg at yahoo.de> wrote:
> 
> Pete, the solution in Weld is a.) breaking other CDI spec paragraphs,

Which ones.

> b.) not clearly mandated

I disagree with this, I think the mandate is clear. The name is specified.

> and c.) randomly depending on the ELResolver order. 

The container must make sure that the ELResolver order is correct.

> 
> 
> It is just not a wise idea.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Mark Struberg <struberg at yahoo.de>
>> Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>> Sent: Wednesday, 14 January 2015, 16:51
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>> 
>> As previously stated I don’t agree with your arguments, and I don’t believe you 
>> can prove “no one is using it”.
>> 
>> 
>>> On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> wrote:
>>> 
>>> No pete, the current Weld implementation breaks other CDI features! Sample 
>> with @Named("javax") already given in my other post...
>>> 
>>> 
>>> It sucks, face it. And no one is using it anyway.
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>> 
>>> 
>>>> ________________________________
>>>> From: Pete Muir <pmuir at redhat.com>
>>>> To: Martin Kouba <mkouba at redhat.com> 
>>>> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
>> <cdi-dev at lists.jboss.org> 
>>>> Sent: Wednesday, 14 January 2015, 13:12
>>>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
>> is not valid in an EL name.
>>>> 
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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