[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Romain Manni-Bucau
rmannibucau at gmail.com
Thu Jan 15 03:23:43 EST 2015
-1 to provide a bean "javax" it is worse than hacking EL to support it
since it also impacts other cases.
That said as Mark showed not having it is not a blocker for a user so
why not just adding the "SHOULD support for EL" since spec(s) dont
proove it is mandatory since EE 6.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-15 9:16 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
> 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