No, it means that since we have the bean name
"javax.enterprise.context.conversation" defined, the following bean
names are not allowed to be defined by a different bean:
javax
javax.enterprise
javax.enterprise.context
and of course javax.enterprise.context.conversation
All the others, e.g. javax.enterprise.foo or javax.bar are fine.
On 01/16/2015 08:20 AM, Romain Manni-Bucau wrote:
>
> 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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto:pmuir at redhat.com>>
> To: Romain
> Manni-Bucau
> <rmannibucau at gmail.com
> <mailto:rmannibucau at gmail.com>>
> Cc: Cdi-dev
> <cdi-dev at lists.jboss.org
> <mailto:cdi-dev at lists.jboss.org>>;
> Edward Burns
>
> <edward.burns at oracle.com
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 <mailto: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
> <mailto: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
> <mailto: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/f0c0a841/attachment-0001.html