[cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL name.
Mark Struberg
struberg at yahoo.de
Fri Jan 16 02:37:18 EST 2015
Hi!
I'm still not sure whether this feature (basically having CDI to introduce own EL namespaces) is really useful. In any case it was a badly advertised if not to say well hidden one.
Otoh if this really IS a feature and the name of our Conversation is not just a special exception then I am ok with implementing this IF we come to the conclusion that it is really ok with the other specs.
Basically we somehow ditch the rest of the whole ELResolver mechanism and 'overrule' it that way.
The overall issue is that we can only detect naming conflicts inside CDI but have no chance to see whether an other ELResolver already occupies that namespace. I'm not sure if the EL EG is aware of what we do with that. This is really a highlander [1] approach, we don't let others air to breath that way. Of course it technically seems legit and also covered by the CDI spec - and it is not up to me alone to decide whether we like to do that or not.
LieGrue,
strub
[1] http://www.c2.com/cgi/wiki?HighlanderPrinciple
> On Friday, 16 January 2015, 8:11, Jozef Hartinger <jharting at redhat.com> wrote:
> > 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.
>>>>>>>>>
>
More information about the cdi-dev
mailing list