[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.

Mark Struberg struberg at yahoo.de
Wed Jan 14 10:52:17 EST 2015


>> Also Weld implementation breaks some valid usages of EL (since
>> it is not done for javax only, right?).
>
> For example?

@Named("javax")
public class MyService {..}

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.
>



More information about the cdi-dev mailing list