[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:06 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/c273c141/attachment-0001.html
More information about the cdi-dev
mailing list