Hmm
Does it mean CDI cant add javax.enterprise.xxx bean? Or even other specs cant add javax.xxx beans?
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@redhat.com>:
On 01/15/2015 11:35 AM, Romain Manni-Bucau wrote:
The spec deals with exactly these types of cases in 5.3.1Hmm not sure. If enriched is a property of the first bean then spec@Named("team1.superBean") and @Named("team1.superBean.enriched") willYes and these conflicts are handled by the spec. See 5.3.1
lead to conflicts and that's things I saw several times in spring apps
which are clearly not possible using CDI + EL properly.
doesn't help.
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@redhat.com>:
On 01/15/2015 11:11 AM, Mark Struberg wrote:
Jozef, your argumentation is flawed already at the very beginning.Mark, please read the e-mail again. I am not saying there are two beans
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.
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@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 andfeatures. This is an XOR situation.
<edward.burns@oracle.com>
LieGrue,
strub
----- Original Message -----
From: Pete Muir <pmuir@redhat.com>
To: Romain Manni-Bucau <rmannibucau@gmail.com>
Cc: Cdi-dev <cdi-dev@lists.jboss.org>; Edward Burns
is not valid in an EL name.Sent: Wednesday, 14 January 2015, 11:56
Subject: Re: [cdi-dev] Answer from EL spec lead: no, "."
not beWe need to go for both (A) and (B).
We would need to deprecate the existing name before we can
allow
it
to
add ansupported. This means CDI 3. So I would suggest we deprecate it
in
2,
In thealternative that can be used, and then consider removing it in
CDI
3.
<rmannibucau@gmail.com>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
<jharting@redhat.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
beenI think further action is needed on this. Now that it has
is not aconfirmed
that "javax.enterprise.context.conversation" itself
property-based approachvalid EL
name we should either:
A) Require all CDI implementations to adapt the
given name,which allows this to be implemented portably (as Weld does)
B) Declare publicly that although the CDI spec declares the
aboutit is a bug and applications should not use the name. (What
from the ELcompatibility 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
an ELSpec Lead.
<edward.burns@oracle.com> wrote:Ed, thanks for helping us!
LieGrue,
strub
On Tuesday, 6 January 2015, 23:14, Edward Burns
Hello Mark,To close this out, no, "." is not valid in
discussed by Petename. An EL name
must
be a java identifier. I'm told this was
provider licensesa long time
ago in the EL 3.0 EG._______________________________________________
Ed
--
| edward.burns@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the
providedthe code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas
propertyon this list, the provider waives all patent and other
intellectual
licenses therights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
providedcode under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas
propertyon this list, the provider waives all patent and other
intellectual
licenses therights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
providedcode under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas
propertyon this list, the provider waives all patent and other
intellectual
coderights inherent in such information.
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
licenses
the
providedunder the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all
other
ideas
propertyon this list, the provider waives all patent and other
intellectual
code under the Apache License, Version 2rights inherent in such information._______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider
licenses
the
(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.