Re: [cdi-dev] getBeanClass return value for build-in beans?
by Werner Keil
Manfred,
For Glassfish probably, but at least the version of JBoss we use here (EAP
6) has these JARs separate at runtime, too.
Werner
On Thu, Aug 13, 2015 at 7:02 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: getBeanClass return value for build-in beans? (Edward Burns)
> 2. Re: getBeanClass return value for build-in beans? (Werner Keil)
> 3. Re: getBeanClass return value for build-in beans? (Werner Keil)
> 4. Re: getBeanClass return value for build-in beans? (manfred riem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Aug 2015 06:44:24 -0700
> From: Edward Burns <edward.burns(a)oracle.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: Manfred Riem <manfred.riem(a)oracle.com>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID: <21964.40760.775241.930217(a)gargle.gargle.HOWL>
> Content-Type: text/plain; charset=us-ascii
>
> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> werner.keil(a)gmail.com> said:
>
> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> >> Some vendors split up this archive in two, an API jar and an impl, jar
> >> (although for JSF 2.3 we don't really encourage this).
>
> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> WK> If the API JAR is no longer separate from the RI (as it was till
> WK> javax.faces-api-2.2.jar
> WK> <
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-ap...
> >)
> WK> it seems, every vendor has to build that API JAR from scratch, or
> carry a
> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
>
> We will be producing a separate API artifact for all the JCP
> milestones.
>
> It is very important to note that the for all Java EE API jars,
> including JSF, the only supported use is to satisfy compile time
> dependencies. Including a Java EE API jar in a runtime classpath is not
> supported and may cause unexpected behavior.
>
> If there is demand we can investigate producing a JSF API jar for
> -SNAPSHOT releases as well.
>
> Ed
>
> --
> | edward.burns(a)oracle.com | office: +1 407 458 0017
> | 58 Business days til JavaOne 2015
> | 73 Business days til DOAG 2015
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Aug 2015 15:55:49 +0200
> From: Werner Keil <werner.keil(a)gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Edward Burns <edward.burns(a)oracle.com>
> Cc: Manfred Riem <manfred.riem(a)oracle.com>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAAGawe0eCfjhTNR5kJSRwYEm9NE45XP6Tf13xUSJQqpxYKvFLA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> OK, thanks for the clarification.
> The way Arjan phrased it sounded like 2.3 would generally keep them in one
> place.
>
> Hence, if separate JARs are something CDI 2 has to consider, getBeanClass()
> and other methods must work for separate API and impl JARs ;-)
>
> Werner
>
> On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns(a)oracle.com>
> wrote:
>
> > >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> > werner.keil(a)gmail.com> said:
> >
> > >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> > >> Some vendors split up this archive in two, an API jar and an impl, jar
> > >> (although for JSF 2.3 we don't really encourage this).
> >
> > WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> > WK> If the API JAR is no longer separate from the RI (as it was till
> > WK> javax.faces-api-2.2.jar
> > WK> <
> >
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-ap...
> > >)
> > WK> it seems, every vendor has to build that API JAR from scratch, or
> > carry a
> > WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
> >
> > We will be producing a separate API artifact for all the JCP
> > milestones.
> >
> > It is very important to note that the for all Java EE API jars,
> > including JSF, the only supported use is to satisfy compile time
> > dependencies. Including a Java EE API jar in a runtime classpath is not
> > supported and may cause unexpected behavior.
> >
> > If there is demand we can investigate producing a JSF API jar for
> > -SNAPSHOT releases as well.
> >
> > Ed
> >
> > --
> > | edward.burns(a)oracle.com | office: +1 407 458 0017
> > | 58 Business days til JavaOne 2015
> > | 73 Business days til DOAG 2015
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/c0e82e18/at...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Aug 2015 16:13:40 +0200
> From: Werner Keil <werner.keil(a)gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: manfred riem <manfred.riem(a)oracle.com>
> Cc: Edward Burns <edward.burns(a)oracle.com>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAAGawe00BozP+doe487V-0XOfAh0TFRrC7P_mdzN=
> XrQayYfYw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Well as of EAP 6.x (Java EE 6) JBoss seems to have them separately also at
> runtime;-)
>
> I don't have a more recent version here, so maybe they'll change it with
> Wildfly...?
>
> Kind Regards,
> Werner
>
> On Thu, Aug 13, 2015 at 4:00 PM, manfred riem <manfred.riem(a)oracle.com>
> wrote:
>
> > Hi Werner,
> >
> > Arjan is correct.
> >
> > The runtime classpath will have the impl JSF 2.3 JAR and it will contain
> > the javax.faces and com.sun.faces packages.
> >
> > The API jar we are referring to will not be part of the runtime classpath
> > and as such should never be on the server runtime classpath, but could be
> > used to compile against (and it will contain only the javax.faces
> packages)
> >
> > Thanks!
> >
> > Kind regards,
> > Manfred Riem
> >
> >
> > On 8/13/15, 8:55 AM, Werner Keil wrote:
> >
> > OK, thanks for the clarification.
> > The way Arjan phrased it sounded like 2.3 would generally keep them in
> one
> > place.
> >
> > Hence, if separate JARs are something CDI 2 has to consider,
> > getBeanClass() and other methods must work for separate API and impl JARs
> > ;-)
> >
> > Werner
> >
> > On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns(a)oracle.com>
> > wrote:
> >
> >> >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil <
> >> werner.keil(a)gmail.com> said:
> >>
> >> >> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> >> >> Some vendors split up this archive in two, an API jar and an impl,
> jar
> >> >> (although for JSF 2.3 we don't really encourage this).
> >>
> >> WK> Could you explain, why the JSF 2.3 API and RI are molded together?
> >> WK> If the API JAR is no longer separate from the RI (as it was till
> >> WK> javax.faces-api-2.2.jar
> >> WK> <
> >>
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-ap...
> >> >)
> >> WK> it seems, every vendor has to build that API JAR from scratch, or
> >> carry a
> >> WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
> >>
> >> We will be producing a separate API artifact for all the JCP
> >> milestones.
> >>
> >> It is very important to note that the for all Java EE API jars,
> >> including JSF, the only supported use is to satisfy compile time
> >> dependencies. Including a Java EE API jar in a runtime classpath is not
> >> supported and may cause unexpected behavior.
> >>
> >> If there is demand we can investigate producing a JSF API jar for
> >> -SNAPSHOT releases as well.
> >>
> >> Ed
> >>
> >> --
> >> | edward.burns(a)oracle.com | office: +1 407 458 0017
> >> | 58 Business days til JavaOne 2015
> >> | 73 Business days til DOAG 2015
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/e9209dd9/at...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Aug 2015 09:00:56 -0500
> From: manfred riem <manfred.riem(a)oracle.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: Edward Burns <edward.burns(a)oracle.com>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID: <55CCA318.3040108(a)oracle.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Werner,
>
> Arjan is correct.
>
> The runtime classpath will have the impl JSF 2.3 JAR and it will contain
> the javax.faces and com.sun.faces packages.
>
> The API jar we are referring to will not be part of the runtime
> classpath and as such should never be on the server runtime classpath,
> but could be used to compile against (and it will contain only the
> javax.faces packages)
>
> Thanks!
>
> Kind regards,
> Manfred Riem
>
> On 8/13/15, 8:55 AM, Werner Keil wrote:
> > OK, thanks for the clarification.
> > The way Arjan phrased it sounded like 2.3 would generally keep them in
> > one place.
> >
> > Hence, if separate JARs are something CDI 2 has to consider,
> > getBeanClass() and other methods must work for separate API and impl
> > JARs ;-)
> >
> > Werner
> >
> > On Thu, Aug 13, 2015 at 3:44 PM, Edward Burns <edward.burns(a)oracle.com
> > <mailto:edward.burns@oracle.com>> wrote:
> >
> > >>>>> On Thu, 13 Aug 2015 15:24:00 +0200, Werner Keil
> > <werner.keil(a)gmail.com <mailto:werner.keil@gmail.com>> said:
> >
> > >> In this particular case it concerns the javax.faces.jar for JSF
> 2.3.
> > >> Some vendors split up this archive in two, an API jar and an
> > impl, jar
> > >> (although for JSF 2.3 we don't really encourage this).
> >
> > WK> Could you explain, why the JSF 2.3 API and RI are molded
> together?
> > WK> If the API JAR is no longer separate from the RI (as it was till
> > WK> javax.faces-api-2.2.jar
> > WK>
> > <
> http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-ap...
> >)
> > WK> it seems, every vendor has to build that API JAR from scratch,
> > or carry a
> > WK> 3-4 MB JAR where the API in 2.2 was just a little under 700kB
> ?;-|
> >
> > We will be producing a separate API artifact for all the JCP
> > milestones.
> >
> > It is very important to note that the for all Java EE API jars,
> > including JSF, the only supported use is to satisfy compile time
> > dependencies. Including a Java EE API jar in a runtime classpath
> > is not
> > supported and may cause unexpected behavior.
> >
> > If there is demand we can investigate producing a JSF API jar for
> > -SNAPSHOT releases as well.
> >
> > Ed
> >
> > --
> > | edward.burns(a)oracle.com <mailto:edward.burns@oracle.com> |
> > office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> > | 58 Business days til JavaOne 2015
> > | 73 Business days til DOAG 2015
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150813/914a6fab/at...
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 57, Issue 8
> **************************************
>
11 years
Re: [cdi-dev] getBeanClass return value for build-in beans?
by Werner Keil
>In this particular case it concerns the javax.faces.jar for JSF 2.3.
>Some vendors split up this archive in two, an API jar and an impl, jar
>(although for JSF 2.3 we don't really encourage this).
Could you explain, why the JSF 2.3 API and RI are molded together?
If the API JAR is no longer separate from the RI (as it was till
javax.faces-api-2.2.jar
<http://search.maven.org/remotecontent?filepath=javax/faces/javax.faces-ap...>)
it seems, every vendor has to build that API JAR from scratch, or carry a
3-4 MB JAR where the API in 2.2 was just a little under 700kB ?;-|
Not to mention often bizarre side-effects if you (accidentially in that
case) mix multiple JSF implementations in some web-apps. I had to resolve
many of those myself between e.g. the JBoss implementation and Apache
RichFaces.
Werner
On Wed, Aug 12, 2015 at 11:07 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. getBeanClass return value for build-in beans? (arjan tijms)
> 2. CDI 2.0 EDR: Questions on asynchronous observers (Nigel Deakin)
> 3. Re: getBeanClass return value for build-in beans?
> (Jozef Hartinger)
> 4. Re: getBeanClass return value for build-in beans? (Martin Kouba)
> 5. Re: CDI 2.0 EDR: Questions on asynchronous observers
> (Jozef Hartinger)
> 6. Re: getBeanClass return value for build-in beans? (arjan tijms)
> 7. Re: getBeanClass return value for build-in beans? (arjan tijms)
>
>
> ----------------------------------------------------------------------
>
> Message: 6
> Date: Wed, 12 Aug 2015 11:07:04 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Jozef Hartinger <jharting(a)redhat.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhAkfzsxZ1pAC6t8bB_4sQ95wWierz_=hGavs7-C0B+2=
> g(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 12, 2015 at 10:10 AM, Jozef Hartinger <jharting(a)redhat.com>
> wrote:
> > Therefore, you are free to use any class as a bean class that:
> > 1) properly identifies the bean archive (i.e. is located in the bean
> archive
> > where you want the custom bean to belong)
>
> In this particular case it concerns the javax.faces.jar for JSF 2.3.
> Some vendors split up this archive in two, an API jar and an impl, jar
> (although for JSF 2.3 we don't really encourage this). Therefor it
> looks like it does make a difference if the Bean<T> implementation
> will return this.class (an implementation type, like Weld does) or say
> Flash.class (an API class).
>
> > What you indicated in the previous e-mails - that Weld does not work
> > properly if the bean class is an abstract class looks like a bug in Weld
> > that I will be investigating.
>
> I'm not 100% sure what the intend is. Is the proxy supposed to only
> implement methods of the Types that are returned by the Bean<T>
> implementation, or should it be smart enough to look at the super
> types of whatever Type is returned?
>
> So given:
>
> public abstract class AbstractClass implements Interface { ... }
>
> If getTypes returns only Abstract.class, then only the methods defined
> by AbstractClass itself are implemented by the proxy. Those from
> Interface throw exceptions when called.
>
> If getTypes returns both Abstract.class and Interface.class, then all
> methods defined by AbstractClass and Interface are implemented by the
> proxy.
>
> Is this how things should be, or should the proxy generator see for
> itself that AbstractClass implements Interface?
>
> Kind regards,
> Arjan Tijms
>
>
> >
> > HTH,
> >
> > Jozef
> >
> >
> >
> >
> > On 11.8.2015 12:26, arjan tijms wrote:
> >>
> >> Hi,
> >>
> >> This is split-off from the thread "Bean<T> that only qualifies super
> >> types?", where the question came up what a Bean<T> should return from
> >> the getBeanClass() method for the case of build-in beans.
> >>
> >> The JavaDoc for getBeanClass() currently says the following:
> >>
> >> "The bean class of the managed bean or session bean or of the bean
> >> that declares the producer method or field."
> >>
> >> See:
> >>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/B...
> >>
> >> The case where a Bean<T> instance is directly created and added as
> >> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >> by this documentation.
> >>
> >> Weld returns "this.class" here.
> >>
> >> See
> >>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se...
> >>
> >> Is that what build-in beans should always do, and if so, should the
> >> JavaDoc/spec be clarified for this?
> >>
> >> Kind regards,
> >> Arjan Tijms
> >> _______________________________________________
> >> 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.
> >>
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 12 Aug 2015 11:07:51 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] getBeanClass return value for build-in beans?
> To: Martin Kouba <mkouba(a)redhat.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhDy_B+mt4kPJqVtP+FAyFEJdzMGC7AS2Qga7=
> q3iVwmcA(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Martin,
>
> On Wed, Aug 12, 2015 at 10:22 AM, Martin Kouba <mkouba(a)redhat.com> wrote:
> > please create a new spec issue. This should be definitely clarified.
>
> I'll do that, thanks!
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Thanks,
> > Martin
> >
> > Dne 12.8.2015 v 10:10 Jozef Hartinger napsal(a):
> >
> >> Hi Arjan,
> >>
> >> the bean class in CDI is used for two purposes:
> >>
> >> 1) to identify the bean archive the bean belongs to (this is crucial for
> >> inter-module injection)
> >> 2) if the bean is an alternative, interceptor or decorator the bean
> >> class is used for matching with beans.xml enablement entries
> >>
> >> Other than these, there are no restrictions imposed by the spec. Note
> >> that there is absolutely no requirement that the bean class is part of
> >> the bean types (as demonstrated by producer method/fields for example).
> >>
> >> Therefore, you are free to use any class as a bean class that:
> >> 1) properly identifies the bean archive (i.e. is located in the bean
> >> archive where you want the custom bean to belong)
> >> 2) if the bean is an alternative, interceptor or decorator then choose
> >> the class whose name you want people to put to beans.xml when enabling
> it
> >>
> >> What you indicated in the previous e-mails - that Weld does not work
> >> properly if the bean class is an abstract class looks like a bug in Weld
> >> that I will be investigating.
> >>
> >> HTH,
> >>
> >> Jozef
> >>
> >>
> >>
> >> On 11.8.2015 12:26, arjan tijms wrote:
> >>>
> >>> Hi,
> >>>
> >>> This is split-off from the thread "Bean<T> that only qualifies super
> >>> types?", where the question came up what a Bean<T> should return from
> >>> the getBeanClass() method for the case of build-in beans.
> >>>
> >>> The JavaDoc for getBeanClass() currently says the following:
> >>>
> >>> "The bean class of the managed bean or session bean or of the bean
> >>> that declares the producer method or field."
> >>>
> >>> See:
> >>>
> https://javaee-spec.java.net/nonav/javadocs/javax/enterprise/inject/spi/B...
> >>>
> >>> The case where a Bean<T> instance is directly created and added as
> >>> bean to AfterBeanDiscovery in an extension does not seem to be covered
> >>> by this documentation.
> >>>
> >>> Weld returns "this.class" here.
> >>>
> >>> See
> >>>
> http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se...
> >>>
> >>> Is that what build-in beans should always do, and if so, should the
> >>> JavaDoc/spec be clarified for this?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>> _______________________________________________
> >>> 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.
> >>
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
>
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 57, Issue 6
> **************************************
>
11 years
CDI 2.0 EDR: Questions on asynchronous observers
by Nigel Deakin
I've read section 10 "Events" of the CDI 2.0 early draft, and have a couple of quick questions about asynchronous
observers.
I'd like to understand how these work with transactions. (I'm referring to normal observer methods here, not the rather
specialised "transactional observer methods")
10.5 states "...An observer method may not directly initiate, commit or rollback JTA transactions."
This wording is unchanged from CDI 1.1. What is the reason for this restriction? I think it might be useful if an
observer method was able to use the JTA API to start and end a transaction, especially when the observer method is being
called asynchronously.
10.5.3 "If the observer method is asynchronous, it is called in... a new transaction context...".
What does "a new transaction context" mean? Does this mean that the container will start a transaction before calling
the observer method? If so, it would be useful if the application could disable this. If not, it would be useful if the
application could itself use the JTA API to start and end a transaction.
Nigel
11 years
Clarification on the difference on Vetoed and exclude filters regarding Java EE component classes
by Emily Jiang
In the section 3.6. Java EE components of CDI 1.2 specification, it has
the following statement:
It is safe to annotate Java EE components with @Vetoed to prevent them
being considered beans.
According to my understanding, the JavaEE component classes with @Vetoed
should still support injections and ProcessInjectionTarget events should
still be fired.
In the 12.4.2, it states:
If the filter is active, and: .... then we say that the type is excluded
from discovery.
Does this mean if a JavaEE component class is excluded from the scan in
the beans.xml, its CDI involvement should be ignored (@Inject would be
ignored etc)?
Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server Liberty Profile development, CDI Development
Lead
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone: +44 (0)1962 816278 Internal: 246278
Email: emijiang(a)uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
11 years
Bean<T> that only qualifies super types?
by arjan tijms
Hi,
I'm wondering if it's possible in CDI to only require a qualifier for
one of the Types in the getTypes collection of a Bean<T>
implementation.
The use case is that I have an abstract class, say Foo, that
implements some interface, say Map:
public abstract class Foo implements Map<String, Object> {
public abstract void someMethod();
}
Then a Bean<T> implementation creates an instance of Foo:
public class MyBean implements Bean<Foo> {
@Override
public Class<?> getBeanClass() {
return Foo.class;
}
@Override
public Set<Type> getTypes() {
return new HashSet<Type>(asList(Foo.class, Map.class));
}
@Override
public Integer create(CreationalContext<Integer> creationalContext) {
return new FooImpl();
}
@Override
public Class<? extends Annotation> getScope() {
return RequestScoped.class;
}
// ...
}
Now the problem is that I don't want to produce Map really, as this
may cause an ambiguity with possibly other Map producers. I only want
to produce Foo.
However, when I limit the getTypes set to contain only Foo:
@Override
public Set<Type> getTypes() {
return new HashSet<Type>(asList(Foo.class));
}
And I subsequently inject Foo:
@Inject
private Foo foo;
And then call a method from Map on foo:
foo.clear();
CDI (Weld 2.2.2.Final in this case) will throw an exception:
"java.lang.AbstractMethodError: Method
org/jboss/weldx/test/Foo$Proxy$_$$_WeldClientProxy.clear()V is
abstract"
So it looks like CDI (Weld) needs Map.class listed in the getTypes
collection to fully create the proxy. Without it, the proxy only
implements methods that are directly defined by Foo (only
someMethod(); in this example).
I therefor would like to add a qualifier such that the Map portion of
the type needs the qualifier:
@Inject @SomeQualifier
private Map map;
But Foo can still be injected without qualifier:
@Inject
private Foo foo;
Is this possible already? Does something in the spec needs to be
changed for this? (the concrete use case btw is the CDI alignment of
JSF 2.3, where I'm trying to create a Bean<T> for
javax.faces.context.Flash)
Kind regards,
Arjan Tijms
11 years
Next meeting on Aug 25th
by Antoine Sabot-Durand
Hi Guys,
I'm on PTO for the 2 coming weeks.
So we'll have our next CDI meeting on august 25th.
Regards,
Antoine
11 years
Re: [cdi-dev] O Captain! My Captain!
by Werner Keil
Pete,
Thanks a lot for your contribution. I started as EC member roughly when JSR
299 went into Public Draft. And among the few in the EC who also still work
on code and in EGs I helped Mike Keith (who also has other duties at Oracle
and is no longer involved in JCP work AFAIK) negotiate and coordinate how
the new JSR 330 (@Inject) and 299 could best work together instead of
reinventing the wheel.
I must say, it went rather well also thanks to Pete and other colleagues.
CDI practically became a synonym for DI since then and plays a more
important role in Java EE with every new version.
I know Antoine since we tried to start a JSR for Social Media on top of
CDI. Which wasn't approved, but we learned a lot in the process and
defining an Open Source project for it instead. So I know, Antoine will
carry the CDI torch well and help ensure, it continues to burn bright in
the Java ecosystem.
All the best for your future role,
Werner
On Fri, Aug 7, 2015 at 10:29 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: O Captain! My Captain! (John D. Ament)
> 2. Tomorrow's agenda (Antoine Sabot-Durand)
> 3. [JBoss JIRA] (CDI-554) Additional built-in beans do not have
> a scope defined (Martin Kouba (JIRA))
> 4. Clarification on the difference on Vetoed and exclude filters
> regarding Java EE component classes (Emily Jiang)
> 5. Bean<T> that only qualifies super types? (arjan tijms)
> 6. Re: Clarification on the difference on Vetoed and exclude
> filters regarding Java EE component classes (Martin Kouba)
> 7. Re: Clarification on the difference on Vetoed and exclude
> filters regarding Java EE component classes (Emily Jiang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 01 Aug 2015 16:19:37 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] O Captain! My Captain!
> To: Pete Muir <pmuir(a)redhat.com>, Antoine Sabot-Durand
> <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAOqetn98z6VcX+0zSqe8N=
> ytacXMy0EfRQRTN1uN2dCxFofJhQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Pete,
>
> Thank you for these last few years. Its been a pleasure seeing the CDI
> ecosystem grow from where it started. All the best!
>
> John
>
> On Thu, Jul 30, 2015 at 10:00 AM Pete Muir <pmuir(a)redhat.com> wrote:
>
> > Thank you everyone for all your help over the last few years, I?ve really
> > enjoyed CDI, and tried to hang on as long as I could. You?ll probably
> have
> > noticed I?ve barely been around for the last 6 months, and so it?s
> > definitely for the best that I leave it in the very capable hands of
> > Antoine :-)
> >
> > Pete
> >
> > > On 30 Jul 2015, at 14:11, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net>
> > wrote:
> > >
> > > Hi Guys,
> > >
> > > Just to inform you that Pete is stepping down his spec lead role on CDI
> > as he's going to take new responsibilities at Red Hat.
> > >
> > > I think that we can thank him for the awesome work he did on CDI from
> > the beginning and wish him good luck for his new adventure in IT.
> > >
> > > Goodbye Pete, and thanks for all the Beans ;)
> > >
> > > Antoine
> > > _______________________________________________
> > > 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150801/e1843ea5/at...
>
> ------------------------------
>
> Message: 2
> Date: Mon, 03 Aug 2015 14:12:10 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Tomorrow's agenda
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CABu-YBS2c3zfuu=ewFoV6vrXsPPVT-b_f=
> jrMDEFmg6m5O6CCw(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> for tomorrow's meeting I propose we start discussing face to face meeting
> content.
>
> If we have time we'll deal with remaining features in Java SE support.
>
> Regards,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150803/a35afa24/at...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 6 Aug 2015 04:20:03 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-554) Additional built-in beans do
> not have a scope defined
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12580458.1438849173000.176286.1438849203512(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
> Martin Kouba created CDI-554:
> --------------------------------
>
> Summary: Additional built-in beans do not have a scope defined
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
>
>
> See section 17.8. Additional built-in beans - a scope is not defined for
> UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined
> somewhere else but I cannot find anything.
>
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and
> ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 6 Aug 2015 14:55:58 +0100
> From: Emily Jiang <EMIJIANG(a)uk.ibm.com>
> Subject: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <
> OFCB816FBA.16D9AE24-ON80257E99.004AC515-80257E99.004C8B38(a)uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> In the section 3.6. Java EE components of CDI 1.2 specification, it has
> the following statement:
>
> It is safe to annotate Java EE components with @Vetoed to prevent them
> being considered beans.
>
> According to my understanding, the JavaEE component classes with @Vetoed
> should still support injections and ProcessInjectionTarget events should
> still be fired.
>
> In the 12.4.2, it states:
> If the filter is active, and: .... then we say that the type is excluded
> from discovery.
>
> Does this mean if a JavaEE component class is excluded from the scan in
> the beans.xml, its CDI involvement should be ignored (@Inject would be
> ignored etc)?
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server Liberty Profile development, CDI Development
> Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: emijiang(a)uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150806/94829138/at...
>
> ------------------------------
>
> Message: 5
> Date: Thu, 6 Aug 2015 18:07:54 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: [cdi-dev] Bean<T> that only qualifies super types?
> To: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhDnoaL=
> 0kF+yZSEMHXzzQ_G6cx0D0FzAyc2-tm0LLcNGQ(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> I'm wondering if it's possible in CDI to only require a qualifier for
> one of the Types in the getTypes collection of a Bean<T>
> implementation.
>
> The use case is that I have an abstract class, say Foo, that
> implements some interface, say Map:
>
> public abstract class Foo implements Map<String, Object> {
> public abstract void someMethod();
> }
>
> Then a Bean<T> implementation creates an instance of Foo:
>
> public class MyBean implements Bean<Foo> {
>
> @Override
> public Class<?> getBeanClass() {
> return Foo.class;
> }
>
> @Override
> public Set<Type> getTypes() {
> return new HashSet<Type>(asList(Foo.class, Map.class));
> }
>
> @Override
> public Integer create(CreationalContext<Integer> creationalContext) {
> return new FooImpl();
> }
>
> @Override
> public Class<? extends Annotation> getScope() {
> return RequestScoped.class;
> }
>
> // ...
> }
>
> Now the problem is that I don't want to produce Map really, as this
> may cause an ambiguity with possibly other Map producers. I only want
> to produce Foo.
>
> However, when I limit the getTypes set to contain only Foo:
>
> @Override
> public Set<Type> getTypes() {
> return new HashSet<Type>(asList(Foo.class));
> }
>
> And I subsequently inject Foo:
>
> @Inject
> private Foo foo;
>
> And then call a method from Map on foo:
>
> foo.clear();
>
> CDI (Weld 2.2.2.Final in this case) will throw an exception:
>
> "java.lang.AbstractMethodError: Method
> org/jboss/weldx/test/Foo$Proxy$_$$_WeldClientProxy.clear()V is
> abstract"
>
> So it looks like CDI (Weld) needs Map.class listed in the getTypes
> collection to fully create the proxy. Without it, the proxy only
> implements methods that are directly defined by Foo (only
> someMethod(); in this example).
>
> I therefor would like to add a qualifier such that the Map portion of
> the type needs the qualifier:
>
> @Inject @SomeQualifier
> private Map map;
>
> But Foo can still be injected without qualifier:
>
> @Inject
> private Foo foo;
>
> Is this possible already? Does something in the spec needs to be
> changed for this? (the concrete use case btw is the CDI alignment of
> JSF 2.3, where I'm trying to create a Bean<T> for
> javax.faces.context.Flash)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 06 Aug 2015 16:24:41 +0200
> From: Martin Kouba <mkouba(a)redhat.com>
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: Emily Jiang <EMIJIANG(a)uk.ibm.com>, cdi-dev(a)lists.jboss.org
> Message-ID: <55C36E29.2040809(a)redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Dne 6.8.2015 v 15:55 Emily Jiang napsal(a):
> > In the section 3.6. Java EE components of CDI 1.2 specification, it has
> > the following statement:
> >
> > /It is safe to annotate Java EE components with //@Vetoed //to prevent
> > them being considered beans./
> >
> > According to my understanding, the JavaEE component classes with @Vetoed
> > should still support injections and *ProcessInjectionTarget*events
> > should still be fired.
> >
> > In the 12.4.2, it states:
> > /If the filter is active, and: .... then we say that the type is
> > excluded from discovery./
> >
> > Does this mean if a JavaEE component class is excluded from the scan in
> > the beans.xml, its CDI involvement should be ignored (@Inject would be
> > ignored etc)?
>
> I don't think so. I believe the intent of "3.6. Java EE components" is
> to clarify that if a component class (e.g. a servlet class) is also
> recognized as a managed bean [1] there will be two different
> "components" in your applicaion, each managed by a different Java EE
> technology - e.g. a servlet managed by the servlet container and a CDI
> bean with servlet class in its set of bean types.
>
> The servlet has a different lifecycle, it's managed by a servlet
> container and as such must support injection (but cannot be injected,
> etc.).
>
> This might be confusing and therefore it's a good idea to veto the Java
> EE component classes -> there will be no CDI bean definitions based on
> the component classes.
>
> [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beans
>
>
> >
> > Many thanks,
> > Emily
> > ===========================
> > Emily Jiang
> > WebSphere Application Server Liberty Profile development, CDI
> > Development Lead
> >
> > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> > Phone: +44 (0)1962 816278 Internal: 246278
> >
> > Email: emijiang(a)uk.ibm.com
> > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > _______________________________________________
> > 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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 7 Aug 2015 09:29:09 +0100
> From: Emily Jiang <EMIJIANG(a)uk.ibm.com>
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed and
> exclude filters regarding Java EE component classes
> To: Martin Kouba <mkouba(a)redhat.com>
> Cc: cdi-dev-bounces(a)lists.jboss.org, cdi-dev(a)lists.jboss.org
> Message-ID:
> <
> OF6AD439B7.C81121A5-ON80257E9A.002E1FCA-80257E9A.002E9F79(a)uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks Martin for your reply! Your reply confirmed my understanding of
> @Vetoed.
>
> What is the expected behaviour if I exclude my JavaEE component class in
> the filter under beans.xml? Will this cause the JavaEE component class
> being ignored by CDI or this should have the same effect as being
> annotated as @Vetoed?
>
> "In the 12.4.2, it states: If the filter is active, and: .... then we say
> that the type is excluded from discovery."
>
> Does the above discovery mean both type and bean discovery or just bean
> discovery? If it means both type and bean discovery, the classes should be
> ignored by CDI. Please confirm.
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server Liberty Profile development, CDI Development
> Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: emijiang(a)uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mkouba(a)redhat.com>
> To: Emily Jiang/UK/IBM@IBMGB, cdi-dev(a)lists.jboss.org,
> Date: 07/08/2015 03:40
> Subject: Re: [cdi-dev] Clarification on the difference on Vetoed
> and exclude filters regarding Java EE component classes
> Sent by: cdi-dev-bounces(a)lists.jboss.org
>
>
>
> Dne 6.8.2015 v 15:55 Emily Jiang napsal(a):
> > In the section 3.6. Java EE components of CDI 1.2 specification, it has
> > the following statement:
> >
> > /It is safe to annotate Java EE components with //@Vetoed //to prevent
> > them being considered beans./
> >
> > According to my understanding, the JavaEE component classes with @Vetoed
> > should still support injections and *ProcessInjectionTarget*events
> > should still be fired.
> >
> > In the 12.4.2, it states:
> > /If the filter is active, and: .... then we say that the type is
> > excluded from discovery./
> >
> > Does this mean if a JavaEE component class is excluded from the scan in
> > the beans.xml, its CDI involvement should be ignored (@Inject would be
> > ignored etc)?
>
> I don't think so. I believe the intent of "3.6. Java EE components" is
> to clarify that if a component class (e.g. a servlet class) is also
> recognized as a managed bean [1] there will be two different
> "components" in your applicaion, each managed by a different Java EE
> technology - e.g. a servlet managed by the servlet container and a CDI
> bean with servlet class in its set of bean types.
>
> The servlet has a different lifecycle, it's managed by a servlet
> container and as such must support injection (but cannot be injected,
> etc.).
>
> This might be confusing and therefore it's a good idea to veto the Java
> EE component classes -> there will be no CDI bean definitions based on
> the component classes.
>
> [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beans
>
>
> >
> > Many thanks,
> > Emily
> > ===========================
> > Emily Jiang
> > WebSphere Application Server Liberty Profile development, CDI
> > Development Lead
> >
> > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> > Phone: +44 (0)1962 816278 Internal: 246278
> >
> > Email: emijiang(a)uk.ibm.com
> > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > _______________________________________________
> > 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.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> 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.
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150807/ddd1f56e/at...
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 57, Issue 2
> **************************************
>
11 years
[JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined
by Martin Kouba (JIRA)
Martin Kouba created CDI-554:
--------------------------------
Summary: Additional built-in beans do not have a scope defined
Key: CDI-554
URL: https://issues.jboss.org/browse/CDI-554
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 2.0-EDR1
Reporter: Martin Kouba
See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything.
In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
Tomorrow's agenda
by Antoine Sabot-Durand
Hi guys,
for tomorrow's meeting I propose we start discussing face to face meeting
content.
If we have time we'll deal with remaining features in Java SE support.
Regards,
Antoine
11 years
