[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Romain Manni-Bucau
rmannibucau at gmail.com
Fri Jan 16 02:20:10 EST 2015
Hmm
Does it mean CDI cant add javax.enterprise.xxx bean? Or even other specs
cant add javax.xxx beans?
Le 16 janv. 2015 08:10, "Jozef Hartinger" <jharting at redhat.com> a écrit :
OK, the relevant part goes:
"If 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."
Let's have:
@Named("team1.superBean.enriched") class Bean1
@Named("team1.superBean") class Bean2
Now
1) "If the bean name of one bean is of the form x.y"
We can match the "x.y" pattern on Bean1's name as:
(team1.superBean) . (enriched)
thus:
x = team1.superBean
y = enriched
2) "where y is a valid bean name"
"enriched" is indeed a valid bean name
3) "and x is the bean name of the other bean"
x ("team1.superBean") is at the same time the name of Bean2
4) Therefore, "the container automatically detects the problem and treats
it as a deployment problem".
Therefore, this scenario does not become a conflict at runtime.
HTH,
Jozef
On 01/15/2015 02:44 PM, Romain Manni-Bucau wrote:
> @Jozef: can you quote it please - sorry if it is obvious but I dont
> see it in 5.3.1, I look 1.2 version BTW. It only deals with names
> where or CDI where here we conflict between resolvers.
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-15 12:59 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
>> On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
>>
>>> @Named("team1.superBean") and @Named("team1.superBean.enriched") will
>>>>> lead to conflicts and that's things I saw several times in spring apps
>>>>> which are clearly not possible using CDI + EL properly.
>>>>>
>>>> Yes and these conflicts are handled by the spec. See 5.3.1
>>>>
>>>> Hmm not sure. If enriched is a property of the first bean then spec
>>> doesn't help.
>>>
>> The spec deals with exactly these types of cases in 5.3.1
>>
>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-01-15 11:22 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>>>>>
>>>>>> On 01/15/2015 11:11 AM, Mark Struberg wrote:
>>>>>>
>>>>>>> Jozef, your argumentation is flawed already at the very beginning.
>>>>>>> Currently there is no bean with the name "javax", thus "x.y ... and x
>>>>>>> is
>>>>>>> the
>>>>>>> bean name of the other bean" will not be a problem.
>>>>>>>
>>>>>>> All that javax is simply not a bean name but a dirty hack in the
>>>>>>> ELResolver. That is something totally different.
>>>>>>>
>>>>>> Mark, please read the e-mail again. I am not saying there are two
>>>>>> beans
>>>>>> named "javax". I am saying there are two beans with the following
>>>>>> names:
>>>>>>
>>>>>> - javax.enterprise.context.conversation (the built-in one)
>>>>>> - javax (Marks's bean)
>>>>>>
>>>>>> where the former one is in form x.y where y is a valid bean name:
>>>>>> (javax) . (enterprise.context.conversation)
>>>>>>
>>>>>> and thus since javax is both x above and a bean name of Mark's bean,
>>>>>> this
>>>>>> results in an exception.
>>>>>>
>>>>>>
>>>>>> Thus the rest of your argumentation chain is also invalid.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, 15 January 2015, 10:47, Jozef Hartinger
>>>>>>>> <jharting at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> T he @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.
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150116/a6dc19b8/attachment-0001.html
More information about the cdi-dev
mailing list