[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