3:46 a.m.
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(a)redhat.com>
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Cc: Cdi-dev <cdi-dev(a)lists.jboss.org>; Edward Burns
<edward.burns(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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.