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

Thu Jan 15 04:46:53 EST 2015

The @Named("javax") argument is not valid. The spec says:

Suppose two beans are both available for injection in a certain war, and 
either:
- the two beans have the same bean name and the name is not resolvable, or
- the bean name of one bean is of the form x.y, where y is a valid bean 
name, and x is the bean
name of the other bean,
the container automatically detects the problem and treats it as a 
deployment problem.

So we have two beans:
- javax.enterprise.context.conversation (the built-in one)
- javax (Marks's bean)

now:

1) the bean name of one bean is of the form x.y, where y is a valid bean 
name - that is javax.enterprise.context.conversation
x = javax
y = enterprise.context.conversation
2) and x is the bean name of the other bean - same as the name of Mark's 
@Named("javax") bean
3) the container automatically detects the problem and treats it as a 
deployment problem

Therefore, a bean named @Named("javax") will cause a deployment problem 
no matter whether it is actually available via EL or not.

To summarize, the spec already anticipates the problem and forbids this 
case explicitly.

On 01/14/2015 04:45 PM, Mark Struberg wrote:
> And then break all applications which have a @Named("javax") public class MyBean?
> It's simply not an option imo. It breaks lots of other specs and features. This is an XOR situation.
>
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Romain Manni-Bucau <rmannibucau at gmail.com>
>> Cc: Cdi-dev <cdi-dev at lists.jboss.org>; Edward Burns <edward.burns at oracle.com>
>> Sent: Wednesday, 14 January 2015, 11:56
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no,	"." is not valid in an EL name.
>>
>> 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.