[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Jozef Hartinger
jharting at redhat.com
Thu Jan 15 04:46:48 EST 2015
After looking into the spec again it became apparent to me that this is
not an issue of a poorly chosen name for a built-in bean as it may look
like at the first glance. Instead, CDI seems to define bean names on top
of EL. It says:
"A valid bean name is a period-separated list of valid EL identifiers."
It even goes further and says:
"The following strings are valid bean names: com.acme.settings"
This means that a bean name *does not have to be a valid EL name*. It
has to be a period-separated list of valid EL identifiers i.e. a valid
EL expression. This implies that a CDI implementation needs to have a
special mechanism for resolving a bean from an EL expression which
recognizes the concept of bean names built on top of EL names (like Weld
does).
On 01/15/2015 09:23 AM, Romain Manni-Bucau wrote:
> -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.
>>>
> _______________________________________________
> 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