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

Mark Struberg struberg at yahoo.de
Wed Jan 14 11:22:31 EST 2015


See my other mail:

@Named("javax")
public class MyService

is a perfectly valid CDI bean. Still it would be broken with Weld.

LieGrue,
strub




----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Wednesday, 14 January 2015, 17:03
> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
> 
> 
>>  On 14 Jan 2015, at 15:59, Mark Struberg <struberg at yahoo.de> wrote:
>> 
>>  Pete, the solution in Weld is a.) breaking other CDI spec paragraphs,
> 
> Which ones.
> 
>>  b.) not clearly mandated
> 
> I disagree with this, I think the mandate is clear. The name is specified.
> 
>>  and c.) randomly depending on the ELResolver order. 
> 
> The container must make sure that the ELResolver order is correct.
> 
> 
>> 
>> 
>>  It is just not a wise idea.
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: Mark Struberg <struberg at yahoo.de>
>>>  Cc: Martin Kouba <mkouba at redhat.com>; Edward Burns 
> <edward.burns at oracle.com>; Cdi-dev <cdi-dev at lists.jboss.org>
>>>  Sent: Wednesday, 14 January 2015, 16:51
>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    "." 
> is not valid in an EL name.
>>> 
>>>  As previously stated I don’t agree with your arguments, and I don’t 
> believe you 
>>>  can prove “no one is using it”.
>>> 
>>> 
>>>>  On 14 Jan 2015, at 15:49, Mark Struberg <struberg at yahoo.de> 
> wrote:
>>>> 
>>>>  No pete, the current Weld implementation breaks other CDI features! 
> Sample 
>>>  with @Named("javax") already given in my other post...
>>>> 
>>>> 
>>>>  It sucks, face it. And no one is using it anyway.
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>  ________________________________
>>>>>  From: Pete Muir <pmuir at redhat.com>
>>>>>  To: Martin Kouba <mkouba at redhat.com> 
>>>>>  Cc: Edward Burns <edward.burns at oracle.com>; Cdi-dev 
>>>  <cdi-dev at lists.jboss.org> 
>>>>>  Sent: Wednesday, 14 January 2015, 13:12
>>>>>  Subject: Re: [cdi-dev] Answer from EL spec lead: no,    
> "." 
>>>  is not valid in an EL name.
>>>>> 
>>>>> 
>>>>> 
>>>>>  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