[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Martin Kouba
mkouba at redhat.com
Thu Jan 15 03:16:33 EST 2015
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 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.
>>
>
> _______________________________________________
> 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