10:19 a.m.
paragraphs and arguing?
Here comes mine:
6.7.5 just defines
"The container provides a built-in bean with bean type Conversation, scope
@RequestScoped, and qualifier @Default, named
javax.enterprise.context.conversation."
It doesn't state that the bean must be available under
#{javax.enterprise.context.conversation} to the EL. This is simply just implicated by the
bean.name rules.
There are 3 usages defined for Bean<T>.getName().
1.) paragraph 3.13 The qualifier @Named at injection points:
It is a Qualifier. Thus you could use
@Inject
@Named("javax.enterprise.context.conversation")
Object conversation;
2.) paragraph 11.3.7 Obtaining a Bean by name:
It makes a bean able to be looked up via BeanManager#getBeans(String)
public Set<Bean<?>>
getBeans("javax.enterprise.context.conversation");
3.) paragraph 2.6 Bean names:
It makes a bean visible to EL. BUT read the specified paragraph really carefula!
"A bean may have a bean name. A bean with a name may be referred to by its name in
Unified EL expressions. A valid bean name is a period-separated list of valid EL
identifiers.
The important part is "list of _VALID_ EL identifiers"
What does this paragraph mean at all?
Does this mean that #{javax} is possible as is #{enterprise}, #{context} and
#{conversation}? Because all those are valid EL identifiers, wheras the combined string is
NOT a valid EL identifier.
If not and we go for your interpretation then we would also need to support code like
@Named("oh.uh.some.other.weird.el.name"}
public class TotallyNonsenseService
You can turn this as you like. It simply makes no sense at all to support it as EL name.
But there is a third option: This is just no valid EL identifier and thus it is not
exposed to EL but only to mechanism 1.) (@Inject @Named) and 2.) (getBeans(String)).
LieGrue,
strub
----- Original Message -----
From: Pete Muir <pmuir(a)redhat.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Jozef Hartinger <jharting(a)redhat.com>; Edward Burns
<edward.burns(a)oracle.com>; Cdi-dev <cdi-dev(a)lists.jboss.org>
Sent: Wednesday, 14 January 2015, 16:49
Subject: Re: [cdi-dev] Answer from EL spec lead: no, "." is not valid in an EL
name.
I’m afraid I disagree with the reasoning you present and your statements below.
> On 14 Jan 2015, at 15:46, Mark Struberg <struberg(a)yahoo.de> wrote:
>
> The spec only says that the Bean must have this name. All the rest is some
3-rd level 'implicit' arguing. The spec does NOT say that the EL
"javax...." must give you a Conversation...
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Pete Muir <pmuir(a)redhat.com>
>> To: Jozef Hartinger <jharting(a)redhat.com>
>> Cc: Edward Burns <edward.burns(a)oracle.com>; Cdi-dev
<cdi-dev(a)lists.jboss.org>
>> Sent: Wednesday, 14 January 2015, 12:20
>> Subject: Re: [cdi-dev] Answer from EL spec lead: no, "."
is not valid in an EL name.
>>
>> I don’t think they should be excluded. The spec isn’t ambiguous about
this, and
>> it is supportable.
>>
>>
>>> On 14 Jan 2015, at 11:13, Jozef Hartinger
<jharting(a)redhat.com>
>> wrote:
>>>
>>> So for CDI 1.2 the test that tests this should not be excluded
after all,
>> correct?
>>>
>>> On 01/14/2015 11:56 AM, Pete Muir wrote:
>>>> 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.
>>