[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