[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Mark Struberg
struberg at yahoo.de
Wed Jan 14 10:52:17 EST 2015
>> Also Weld implementation breaks some valid usages of EL (since
>> it is not done for javax only, right?).
>
> For example?
@Named("javax")
public class MyService {..}
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> 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 at gmail.com>
> 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 at redhat.com>:
>>> 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 at gmail.com> 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 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.
>>>>>>>
>>>>>>>
>>>>>
>>>
>
>
> _______________________________________________
> 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