From struberg at yahoo.de Sun Feb 2 16:01:26 2014 From: struberg at yahoo.de (Mark Struberg) Date: Sun, 2 Feb 2014 21:01:26 +0000 (GMT) Subject: [cdi-dev] bean archive != bean archive Message-ID: <1391374886.46639.YahooMailNeo@web28902.mail.ir2.yahoo.com> Hi folks! Old story again: The spec is not really clear imo what the term 'bean archive' (aka BDA) does mean. The section 5.1 (Modularity) indicates that a bunch of jars might get interpreted as a 'bean archive', which in hindsight of isolation makes sense. E.g. it does not make sense that beans from different jars in an EARs shared lib folder cannot 'see' each other in respect to CDI. This is the one which also applies to cdi-1.0 @Alternatives and @Interceptor rules, right? Otoh there is also section 12 which uses the same term 'bean archive' for single JARs (or ClassPath entries like WEB-INF/classes). So which one should be it? Imo the 2 are fundamentally different. Any ideas or comments?Did I get this wrong? LieGrue, strub -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140202/ed2eff8a/attachment.html From issues at jboss.org Mon Feb 3 03:38:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 03:38:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-389. -------------------------------------- Resolution: Done > Revert CDI-85 > ------------- > > Key: CDI-389 > URL: https://issues.jboss.org/browse/CDI-389 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Bullet 4 of section 5.2.4 should be reverted back from: > {quote} > the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from* > the upper bound, if any, of the type variable, or > {quote} > to > {quote} > the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to* > the upper bound, if any, of the type variable, or > {quote} > See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 04:28:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 04:28:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-418: ---------------------------------------- Summary: 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 Key: CDI-418 URL: https://issues.jboss.org/browse/CDI-418 Project: CDI Specification Issues Issue Type: Bug Components: Javadoc and API Affects Versions: 1.2 Proposed Reporter: Antoine Sabot-Durand It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From mkouba at redhat.com Mon Feb 3 04:49:29 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 03 Feb 2014 10:49:29 +0100 Subject: [cdi-dev] exclude rules questions In-Reply-To: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: <52EF6629.6000801@redhat.com> Hi Mark, Dne 31.1.2014 21:07, Mark Struberg napsal(a): > > > Hi! > > A few questions regarding exclude rules > > 1.) does .* mean only the package, but no sub-packages. Whereas .** also includes sub-packages? > Marek brought up another interesting note: com.foo.** would according to the wording also exclude com.foobar... Is that intended? > Yes, types from "com.foobar" would be excluded as well. I'm not sure it was intended but we should not change the behaviour due to backwards compatibility... > > 2.) Are multiple children allowed in an exclude rule in beans.xml? Yep, check also the schema file (beans_1_1.xsd). > There is a funny example in the spec: > > > > > > > > > > But I could not find the explanation what should happen. The if-class-available is nowhere stated. Or did I overlook it? > "if-class-available" is described above the example and in xsd. The filter is active only if the classloader for the bean archive CAN load a class for that name. So the filter will not be active if the "Model" class can't be loaded or if the system property "exclude-ejbs" is not set. In any case the description of the example is not complete and we should add a TCK test for this as well (AFAIK org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not testing multiple child elements). > txs and LieGrue, > strub > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > From issues at jboss.org Mon Feb 3 04:56:28 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 3 Feb 2014 04:56:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940713#comment-12940713 ] Mark Struberg commented on CDI-382: ----------------------------------- Please try to not introduce a spec change. I suggest a wording like 'Any InterceptorBinding of a producer field or producer method does not apply to the produced contextual instance but intercepts the invocation of the producer method or producer field itself' It is possible that e.g. a producer method returns a contextual instance which is already wrapped with an interception-proxy. > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From struberg at yahoo.de Mon Feb 3 05:02:19 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 3 Feb 2014 10:02:19 +0000 (GMT) Subject: [cdi-dev] Time for homework picking In-Reply-To: References: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net> <52EA5856.7030405@redhat.com> Message-ID: <1391421739.24839.YahooMailNeo@web28904.mail.ir2.yahoo.com> I can take over CDI-392. LieGrue, strub On Thursday, 30 January 2014, 15:25, Antoine Sabot-Durand wrote: Great Martin. > >Taking CDI-413 and CDI-389 > >Antoine > > > >Le 30 janv. 2014 ? 14:49, Martin Kouba a ?crit : > >> Hi, >> >> I've taken CDI-382 and CDI-318. >> >> M >> >> Dne 30.1.2014 14:20, Antoine Sabot-Durand napsal(a): >>> Hi guys, >>> >>> We've got a bunch of task ready to be fixed. So if you can/want, it?s time to pick a ticket. I?ve built a list of unassigned task ready to be fixed [1]. >>> So make your choice by assigning the ticket to you or by asking me. >>> Don?t forget the workflow we approved on monday >>> >>> Regards, >>> >>> Antoine >>> >>>? From antoine at sabot-durand.net Mon Feb 3 05:07:30 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Feb 2014 11:07:30 +0100 Subject: [cdi-dev] Time for homework picking In-Reply-To: <1391421739.24839.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <9AC85A18-9DAD-47F2-A0FF-348867637306@sabot-durand.net> <52EA5856.7030405@redhat.com> <1391421739.24839.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: It?s yours Mark. Antoine Le 3 f?vr. 2014 ? 11:02, Mark Struberg a ?crit : > I can take over CDI-392. > > > LieGrue, > strub > > > > > > > On Thursday, 30 January 2014, 15:25, Antoine Sabot-Durand wrote: > > Great Martin. >> >> Taking CDI-413 and CDI-389 >> >> Antoine >> >> >> >> Le 30 janv. 2014 ? 14:49, Martin Kouba a ?crit : >> >>> Hi, >>> >>> I've taken CDI-382 and CDI-318. >>> >>> M >>> >>> Dne 30.1.2014 14:20, Antoine Sabot-Durand napsal(a): >>>> Hi guys, >>>> >>>> We've got a bunch of task ready to be fixed. So if you can/want, it?s time to pick a ticket. I?ve built a list of unassigned task ready to be fixed [1]. >>>> So make your choice by assigning the ticket to you or by asking me. >>>> Don?t forget the workflow we approved on monday >>>> >>>> Regards, >>>> >>>> Antoine >>>> >>>> From issues at jboss.org Mon Feb 3 05:08:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 05:08:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-392: ------------------------------------- Assignee: Mark Struberg > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From struberg at yahoo.de Mon Feb 3 05:11:15 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 3 Feb 2014 10:11:15 +0000 (GMT) Subject: [cdi-dev] exclude rules questions In-Reply-To: <52EF6629.6000801@redhat.com> References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF6629.6000801@redhat.com> Message-ID: <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> ad 1.) Well, I do not entirely agree with the foobar also being excluded. The spec says: "" "The fourth exclude filter will exclude all classes in the com.acme.ejb package, and any subpackages if the system property exclude-ejbs is set (with any value)." Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package. >From a user view I'd say it makes no sense to also exclude ejbrother. ad 2.) We must clarify whether multiple conditions in a element are OR or AND. LieGrue, strub > On Monday, 3 February 2014, 10:49, Martin Kouba wrote: > > Hi Mark, > > Dne 31.1.2014 21:07, Mark Struberg napsal(a): >> >> >>??Hi! >> >>??A few questions regarding exclude rules >> >>??1.) does .* mean only the package, but no sub-packages. Whereas .** also > includes sub-packages? >>??Marek brought up another interesting note: com.foo.** would according to > the wording also exclude com.foobar... Is that intended? >> > > Yes, types from "com.foobar" would be excluded as well. I'm not > sure it > was intended but we should not change the behaviour due to backwards > compatibility... > >> >>??2.) Are multiple children allowed in an exclude rule in beans.xml? > > Yep, check also the schema file (beans_1_1.xsd). > >>??There is a funny example in the spec: >> >>?? >> >> ??? name="javax.enterprise.inject.Model"/> >> >> ??? >>?? >> >> >>??But I could not find the explanation what should happen. The > if-class-available is nowhere stated. Or did I overlook it? >> > > "if-class-available" is described above the example and in xsd. The > filter is active only if the classloader for the bean archive CAN > load a class for that name. So the filter will not be active if the > "Model" class can't be loaded or if the system property > "exclude-ejbs" > is not set. > > In any case the description of the example is not complete and we should > add a TCK test for this as well (AFAIK > org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not > testing multiple child elements). > > >>??txs and LieGrue, >>??strub >> >> >>??_______________________________________________ >>??cdi-dev mailing list >>??cdi-dev at lists.jboss.org >>??https://lists.jboss.org/mailman/listinfo/cdi-dev >> > From issues at jboss.org Mon Feb 3 05:36:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 05:36:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-368) Bullet points not rendered properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-368: ---------------------------------------- Assignee: Antoine Sabot-Durand (was: Pete Muir) > Bullet points not rendered properly > ----------------------------------- > > Key: CDI-368 > URL: https://issues.jboss.org/browse/CDI-368 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Priority: Minor > > 1) Open http://docs.jboss.org/cdi/spec/1.1/cdi-spec.pdf > 2) Search for "*" > There are multiple occasions where the bullet point is not rendered properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 05:42:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 05:42:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-368) Bullet points not rendered properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-368: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/191 Pull Request proposed in april 2013 by Martin Kouba > Bullet points not rendered properly > ----------------------------------- > > Key: CDI-368 > URL: https://issues.jboss.org/browse/CDI-368 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Priority: Minor > > 1) Open http://docs.jboss.org/cdi/spec/1.1/cdi-spec.pdf > 2) Search for "*" > There are multiple occasions where the bullet point is not rendered properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From mkouba at redhat.com Mon Feb 3 05:45:24 2014 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 03 Feb 2014 11:45:24 +0100 Subject: [cdi-dev] exclude rules questions In-Reply-To: <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF6629.6000801@redhat.com> <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> Message-ID: <52EF7344.8070900@redhat.com> Dne 3.2.2014 11:11, Mark Struberg napsal(a): > > > > ad 1.) > > Well, I do not entirely agree with the foobar also being excluded. The spec says: > > "" > > "The fourth exclude filter will exclude all classes in the com.acme.ejb package, and any subpackages if the system property exclude-ejbs is set (with any value)." > > Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package. > From a user view I'd say it makes no sense to also exclude ejbrother. > Yes. But it's only an example description which indicates it was not intended. IMO the authoritative statement is: "the package name of the type being discovered starts with the value of the name attribute with a suffix ".**" of the exclude filter" > > ad 2.) > > We must clarify whether multiple conditions in a element are OR or AND. I think it's OR because the spec states: "If the exclude filter definition contains: * ...condition, OR then the filter is inactive." > > LieGrue, > strub > > > > >> On Monday, 3 February 2014, 10:49, Martin Kouba wrote: >>> Hi Mark, >> >> Dne 31.1.2014 21:07, Mark Struberg napsal(a): >>> >>> >>> Hi! >>> >>> A few questions regarding exclude rules >>> >>> 1.) does .* mean only the package, but no sub-packages. Whereas .** also >> includes sub-packages? >>> Marek brought up another interesting note: com.foo.** would according to >> the wording also exclude com.foobar... Is that intended? >>> >> >> Yes, types from "com.foobar" would be excluded as well. I'm not >> sure it >> was intended but we should not change the behaviour due to backwards >> compatibility... >> >>> >>> 2.) Are multiple children allowed in an exclude rule in beans.xml? >> >> Yep, check also the schema file (beans_1_1.xsd). >> >>> There is a funny example in the spec: >>> >>> >>> >>> > name="javax.enterprise.inject.Model"/> >>> >>> >>> >>> >>> >>> But I could not find the explanation what should happen. The >> if-class-available is nowhere stated. Or did I overlook it? >>> >> >> "if-class-available" is described above the example and in xsd. The >> filter is active only if the classloader for the bean archive CAN >> load a class for that name. So the filter will not be active if the >> "Model" class can't be loaded or if the system property >> "exclude-ejbs" >> is not set. >> >> In any case the description of the example is not complete and we should >> add a TCK test for this as well (AFAIK >> org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not >> testing multiple child elements). >> >> >>> txs and LieGrue, >>> strub >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> From issues at jboss.org Mon Feb 3 05:48:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 05:48:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-368) Bullet points not rendered properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-368. -------------------------------------- Fix Version/s: 1.2 Proposed Resolution: Done PR merged. Other typos may exist. > Bullet points not rendered properly > ----------------------------------- > > Key: CDI-368 > URL: https://issues.jboss.org/browse/CDI-368 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Priority: Minor > Fix For: 1.2 Proposed > > > 1) Open http://docs.jboss.org/cdi/spec/1.1/cdi-spec.pdf > 2) Search for "*" > There are multiple occasions where the bullet point is not rendered properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 06:12:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 06:12:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-234) behavior of arrays without @Nonbinding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-234: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/79 A PR has been proposed by Pete but it's now closed because we switch spec to Asciidoc meanwhile. However its content may still be relevant for a futur evolution. > behavior of arrays without @Nonbinding > -------------------------------------- > > Key: CDI-234 > URL: https://issues.jboss.org/browse/CDI-234 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Romain Manni-Bucau > Assignee: Pete Muir > Priority: Minor > Fix For: TBD > > > The spec says: > "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. > If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior > results." > The case of arrays without this annotation should be managed to get a better portability. The equality of arrays is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotation.html) so i don't think there is any technical issue to consider arrays as a field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 06:22:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 06:22:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-110) Provide support for binding an invocation handler to an interface or abstract class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-110: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/28 (was: https://github.com/jboss/cdi/pull/28) > Provide support for binding an invocation handler to an interface or abstract class > ----------------------------------------------------------------------------------- > > Key: CDI-110 > URL: https://issues.jboss.org/browse/CDI-110 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Inheritance and Specialization > Affects Versions: 1.0 > Reporter: George Gastaldi > Labels: cdi > Fix For: TBD > > > The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding. > Binding type: > {code:java} > @Target({ METHOD, TYPE }) > @Retention(RetentionPolicy.RUNTIME) > @ServiceHandlerBindingType > public @interface EchoService {} > {code} > Invocation handler: > {code:java} > @ServiceHandler > @EchoService > public class EchoServiceHandler { > @AroundInvoke > public Object invoke(InvocationContext ctx) { > return ctx.getMethod().getName().toString(); > } > } > {code} > Usage: > {code:java} > @EchoService > public interface HelloWorld { > String helloWorld(); > } > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From struberg at yahoo.de Mon Feb 3 07:02:23 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 3 Feb 2014 12:02:23 +0000 (GMT) Subject: [cdi-dev] exclude rules questions In-Reply-To: <52EF7344.8070900@redhat.com> References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF6629.6000801@redhat.com> <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF7344.8070900@redhat.com> Message-ID: <1391428943.92189.YahooMailNeo@web28902.mail.ir2.yahoo.com> If you do a word-by-word interpretation of the spec, then even the .* paragraph would include sub-packages. But that does not make sense from a user perspective! The spec contradicts itself in this regard. And in this case we should pick the option which is most likely the one the user wants. This case will really rarely be hit in the wild though. Let's look what other established Java mechanism do in this area: ?* OSGi: it only knows .* (no .** over there afaik) but while this also covers sub-packages ,foo.* does _not_ cover foobar. ?* Maven: knows .* and .**. foo.* does _not_ cover foobar neither Feel free to point me to _important_ Java projects where foobar gets covered by foo.** LieGrue, strub > On Monday, 3 February 2014, 11:45, Martin Kouba wrote: > > Dne 3.2.2014 11:11, Mark Struberg napsal(a): >> >> >> >> ad 1.) >> >> Well, I do not entirely agree with the foobar also being excluded. The spec > says: >> >> "" >> >> "The fourth exclude filter will exclude all classes in the > com.acme.ejb package, and any subpackages if the system property exclude-ejbs is > set (with any value)." >> >> Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package. >> From a user view I'd say it makes no sense to also exclude ejbrother. >> > > Yes. But it's only an example description which indicates it was not > intended. > > IMO the authoritative statement is: > "the package name of the type being discovered starts with the value of > the name attribute with a suffix ".**" of the exclude filter" > >> >> ad 2.) >> >> We must clarify whether multiple conditions in a element are > OR or AND. > > I think it's OR because the spec states: > "If the exclude filter definition contains: > * ...condition, OR > then the filter is inactive." > > >> >> LieGrue, >> strub >> >> >> >> >>> On Monday, 3 February 2014, 10:49, Martin Kouba > wrote: >>>> Hi Mark, >>> >>> Dne 31.1.2014 21:07, Mark Struberg napsal(a): >>>> >>>> >>>> ? Hi! >>>> >>>> ? A few questions regarding exclude rules >>>> >>>> ? 1.) does .* mean only the package, but no sub-packages. Whereas > .** also >>> includes sub-packages? >>>> ? Marek brought up another interesting note: com.foo.** would > according to >>> the wording also exclude com.foobar... Is that intended? >>>> >>> >>> Yes, types from "com.foobar" would be excluded as well. > I'm not >>> sure it >>> was intended but we should not change the behaviour due to backwards >>> compatibility... >>> >>>> >>>> ? 2.) Are multiple children allowed in an exclude rule in > beans.xml? >>> >>> Yep, check also the schema file (beans_1_1.xsd). >>> >>>> ? There is a funny example in the spec: >>>> >>>> ? >>>> >>>> ? ? >> name="javax.enterprise.inject.Model"/> >>>> >>>> ? ? >>>> ? >>>> >>>> >>>> ? But I could not find the explanation what should happen. The >>> if-class-available is nowhere stated. Or did I overlook it? >>>> >>> >>> "if-class-available" is described above the example and in > xsd. The >>> filter is active only if the classloader for the bean archive CAN >>> load a class for that name. So the filter will not be active if the >>> "Model" class can't be loaded or if the system property >>> "exclude-ejbs" >>> is not set. >>> >>> In any case the description of the example is not complete and we > should >>> add a TCK test for this as well (AFAIK >>> org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not >>> testing multiple child elements). >>> >>> >>>> ? txs and LieGrue, >>>> ? strub >>>> >>>> >>>> ? _______________________________________________ >>>> ? cdi-dev mailing list >>>> ? cdi-dev at lists.jboss.org >>>> ? https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>> > From rmannibucau at gmail.com Mon Feb 3 07:08:41 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 3 Feb 2014 13:08:41 +0100 Subject: [cdi-dev] exclude rules questions In-Reply-To: <1391428943.92189.YahooMailNeo@web28902.mail.ir2.yahoo.com> References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF6629.6000801@redhat.com> <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF7344.8070900@redhat.com> <1391428943.92189.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: +1 we should stay as much as possible to java world and not regex one which always makes things hard to follow...and here it would be pretty useless Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-03 Mark Struberg : > If you do a word-by-word interpretation of the spec, then even the .* paragraph would include sub-packages. But that does not make sense from a user perspective! > > > The spec contradicts itself in this regard. And in this case we should pick the option which is most likely the one the user wants. This case will really rarely be hit in the wild though. > > Let's look what other established Java mechanism do in this area: > > * OSGi: it only knows .* (no .** over there afaik) but while this also covers sub-packages ,foo.* does _not_ cover foobar. > > * Maven: knows .* and .**. foo.* does _not_ cover foobar neither > > > Feel free to point me to _important_ Java projects where foobar gets covered by foo.** > > > LieGrue, > strub > > > > >> On Monday, 3 February 2014, 11:45, Martin Kouba wrote: >> > Dne 3.2.2014 11:11, Mark Struberg napsal(a): >>> >>> >>> >>> ad 1.) >>> >>> Well, I do not entirely agree with the foobar also being excluded. The spec >> says: >>> >>> "" >>> >>> "The fourth exclude filter will exclude all classes in the >> com.acme.ejb package, and any subpackages if the system property exclude-ejbs is >> set (with any value)." >>> >>> Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package. >>> From a user view I'd say it makes no sense to also exclude ejbrother. >>> >> >> Yes. But it's only an example description which indicates it was not >> intended. >> >> IMO the authoritative statement is: >> "the package name of the type being discovered starts with the value of >> the name attribute with a suffix ".**" of the exclude filter" >> >>> >>> ad 2.) >>> >>> We must clarify whether multiple conditions in a element are >> OR or AND. >> >> I think it's OR because the spec states: >> "If the exclude filter definition contains: >> * ...condition, OR >> then the filter is inactive." >> >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>>> On Monday, 3 February 2014, 10:49, Martin Kouba >> wrote: >>>>> Hi Mark, >>>> >>>> Dne 31.1.2014 21:07, Mark Struberg napsal(a): >>>>> >>>>> >>>>> Hi! >>>>> >>>>> A few questions regarding exclude rules >>>>> >>>>> 1.) does .* mean only the package, but no sub-packages. Whereas >> .** also >>>> includes sub-packages? >>>>> Marek brought up another interesting note: com.foo.** would >> according to >>>> the wording also exclude com.foobar... Is that intended? >>>>> >>>> >>>> Yes, types from "com.foobar" would be excluded as well. >> I'm not >>>> sure it >>>> was intended but we should not change the behaviour due to backwards >>>> compatibility... >>>> >>>>> >>>>> 2.) Are multiple children allowed in an exclude rule in >> beans.xml? >>>> >>>> Yep, check also the schema file (beans_1_1.xsd). >>>> >>>>> There is a funny example in the spec: >>>>> >>>>> >>>>> >>>>> >>> name="javax.enterprise.inject.Model"/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> But I could not find the explanation what should happen. The >>>> if-class-available is nowhere stated. Or did I overlook it? >>>>> >>>> >>>> "if-class-available" is described above the example and in >> xsd. The >>>> filter is active only if the classloader for the bean archive CAN >>>> load a class for that name. So the filter will not be active if the >>>> "Model" class can't be loaded or if the system property >>>> "exclude-ejbs" >>>> is not set. >>>> >>>> In any case the description of the example is not complete and we >> should >>>> add a TCK test for this as well (AFAIK >>>> org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not >>>> testing multiple child elements). >>>> >>>> >>>>> txs and LieGrue, >>>>> strub >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From issues at jboss.org Mon Feb 3 07:30:28 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 3 Feb 2014 07:30:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940743#comment-12940743 ] Martin Kouba commented on CDI-318: ---------------------------------- [~antoinesabot-durand] I wonder if there's some convention to refer a specific part the spec text in javadoc. In this case the text in "11.5.6 ProcessAnnotatedType event" refers to "Section 11.4". > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Martin Kouba > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 07:50:28 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 3 Feb 2014 07:50:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-59) Clarify interceptors/decorators aren't applied to the *result* of a producer method or producer field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940753#comment-12940753 ] Martin Kouba commented on CDI-59: --------------------------------- For the record: I don't understand fully the notices about decorators. The spec clearly states that: bq. Invocations of producer, disposer and observer methods by the container are business method invocations and are intercepted by method interceptors and decorators. > Clarify interceptors/decorators aren't applied to the *result* of a producer method or producer field > ----------------------------------------------------------------------------------------------------- > > Key: CDI-59 > URL: https://issues.jboss.org/browse/CDI-59 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Decorators, Interceptors, Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.PRD > > > Interceptors can be applied to the invocation of a producer method, but not to a bean produced by a producer method. Decorators cannot be applied -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:06:28 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 3 Feb 2014 08:06:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940758#comment-12940758 ] Martin Kouba commented on CDI-382: ---------------------------------- [~struberg] your suggestion makes sense. Except that producer field may not declare an interceptor binding (see interceptors spec, 3.3 Binding an Interceptor to a Component). Also interceptor binding itself does not intercept anything. What about this: bq. Interceptor bindings declared on a producer method are not applied to the return value of such method. > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:12:28 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Mon, 3 Feb 2014 08:12:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940759#comment-12940759 ] Arne Limburg commented on CDI-382: ---------------------------------- And the wording should contain the case that the producer method is annotated with a @Stereotype Annotation, that contains an interceptor binding and a qualifier. I guess, the qualifier will be applied to the result and the interceptor will be applied to the method call (which is odd anyway)? > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From jharting at redhat.com Mon Feb 3 08:19:57 2014 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 03 Feb 2014 14:19:57 +0100 Subject: [cdi-dev] bean archive != bean archive In-Reply-To: <1391374886.46639.YahooMailNeo@web28902.mail.ir2.yahoo.com> References: <1391374886.46639.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: <52EF977D.3070902@redhat.com> Yes, this seems wrong. For EJB modules and libraries this is fine but there seems to be a conflict between 5.1 and 12.1 for WAR modules. Also, implicit bean archives do not seem to be reflected within 5.1. On 02/02/2014 10:01 PM, Mark Struberg wrote: > Hi folks! > > Old story again: > The spec is not really clear imo what the term 'bean archive' (aka > BDA) does mean. > > The section 5.1 (Modularity) indicates that a bunch of jars might get > interpreted as a 'bean archive', which in hindsight of isolation makes > sense. E.g. it does not make sense that beans from different jars in > an EARs shared lib folder cannot 'see' each other in respect to CDI. > This is the one which also applies to cdi-1.0 @Alternatives and > @Interceptor rules, right? > > Otoh there is also section 12 which uses the same term 'bean archive' > for single JARs (or ClassPath entries like WEB-INF/classes). > > So which one should be it? Imo the 2 are fundamentally different. > > Any ideas or comments? Did I get this wrong? > > LieGrue, > strub > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/f6fe855b/attachment.html From issues at jboss.org Mon Feb 3 08:28:28 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 3 Feb 2014 08:28:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940764#comment-12940764 ] Martin Kouba commented on CDI-382: ---------------------------------- [~arnelim] I believe the qualifier will not be applied to the return value, only to the producer method (aka bean definition). > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 08:30:29 2014 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Mon, 3 Feb 2014 08:30:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940766#comment-12940766 ] Arne Limburg commented on CDI-382: ---------------------------------- That's what I was talking about ;-) > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 3 09:12:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 3 Feb 2014 09:12:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12940783#comment-12940783 ] Antoine Sabot-Durand commented on CDI-318: ------------------------------------------ [~mkouba] yes section "11.5.6" seems good. And don't forget the main convention : Java Standard Rules. I think we should take that as a rule of thumb : when we're not following JSL and that we do not explicit write it, we're (probably) wrong. That works here ;) > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Martin Kouba > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Mon Feb 3 09:52:27 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Feb 2014 15:52:27 +0100 Subject: [cdi-dev] Today's meeting and free node DoS Message-ID: <2628FB85-0280-4D82-811B-81CCF00F7CA1@sabot-durand.net> Hi all, Apparently Freenode have been down since last night due to DoS. I propose that we cancel tonight?s meeting. We stay in touch trhu the ML and Jira anyway. Regards, Antoine From struberg at yahoo.de Mon Feb 3 09:52:39 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 3 Feb 2014 14:52:39 +0000 (GMT) Subject: [cdi-dev] freenode down. where to do our EG meeting today? Message-ID: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> Hi! Not sure whether freenode is up again in the evening. Where do we meet if not? LieGrue, strub From antoine at sabot-durand.net Mon Feb 3 10:19:11 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Feb 2014 16:19:11 +0100 Subject: [cdi-dev] freenode down. where to do our EG meeting today? In-Reply-To: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> References: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> Message-ID: <84F12867-E9C7-4FAC-8D55-D7368184A67F@sabot-durand.net> Hi Mark, As I said in my previous mail I think we?re going quite well with Jira and ML so we can postpone the meeting, except if you have important matters than needs synchronous conversation ;). Antoine Le 3 f?vr. 2014 ? 15:52, Mark Struberg a ?crit : > Hi! > > Not sure whether freenode is up again in the evening. Where do we meet if not? > > LieGrue, > strub > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From struberg at yahoo.de Mon Feb 3 11:10:05 2014 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 3 Feb 2014 16:10:05 +0000 (GMT) Subject: [cdi-dev] freenode down. where to do our EG meeting today? In-Reply-To: <84F12867-E9C7-4FAC-8D55-D7368184A67F@sabot-durand.net> References: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> <84F12867-E9C7-4FAC-8D55-D7368184A67F@sabot-durand.net> Message-ID: <1391443805.79926.YahooMailNeo@web28906.mail.ir2.yahoo.com> chat.freenode.net is up. LieGrue, strub > On Monday, 3 February 2014, 16:19, Antoine Sabot-Durand wrote: > > Hi Mark, > > As I said in my previous mail I think we?re going quite well with Jira and ML so > we can postpone the meeting, except if you have important matters than needs > synchronous conversation ;). > > Antoine > > > > Le 3 f?vr. 2014 ? 15:52, Mark Struberg a ?crit : > >> Hi! >> >> Not sure whether freenode is up again in the evening. Where do we meet if > not? >> >> LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > From antoine at sabot-durand.net Mon Feb 3 11:14:05 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Feb 2014 17:14:05 +0100 Subject: [cdi-dev] freenode down. where to do our EG meeting today? In-Reply-To: <1391443805.79926.YahooMailNeo@web28906.mail.ir2.yahoo.com> References: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> <84F12867-E9C7-4FAC-8D55-D7368184A67F@sabot-durand.net> <1391443805.79926.YahooMailNeo@web28906.mail.ir2.yahoo.com> Message-ID: <95BEE00C-2AF8-4592-8E4D-51C8891C1140@sabot-durand.net> Unable yo connect on my side. Antoine Le 3 f?vr. 2014 ? 17:10, Mark Struberg a ?crit : > chat.freenode.net is up. > > LieGrue, > strub > > > > > >> On Monday, 3 February 2014, 16:19, Antoine Sabot-Durand wrote: >>> Hi Mark, >> >> As I said in my previous mail I think we?re going quite well with Jira and ML so >> we can postpone the meeting, except if you have important matters than needs >> synchronous conversation ;). >> >> Antoine >> >> >> >> Le 3 f?vr. 2014 ? 15:52, Mark Struberg a ?crit : >> >>> Hi! >>> >>> Not sure whether freenode is up again in the evening. Where do we meet if >> not? >>> >>> LieGrue, >>> strub >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> From antoine at sabot-durand.net Mon Feb 3 11:32:34 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 3 Feb 2014 17:32:34 +0100 Subject: [cdi-dev] freenode down. where to do our EG meeting today? In-Reply-To: <1391443805.79926.YahooMailNeo@web28906.mail.ir2.yahoo.com> References: <1391439159.53651.YahooMailNeo@web28904.mail.ir2.yahoo.com> <84F12867-E9C7-4FAC-8D55-D7368184A67F@sabot-durand.net> <1391443805.79926.YahooMailNeo@web28906.mail.ir2.yahoo.com> Message-ID: I?m in #JSR346 chan. If some of you want to discuss at 5:00pm GMT. I?ll be around. But I thinks there are still issues on freenode Antoine Le 3 f?vr. 2014 ? 17:10, Mark Struberg a ?crit : > chat.freenode.net is up. > > LieGrue, > strub > > > > > >> On Monday, 3 February 2014, 16:19, Antoine Sabot-Durand wrote: >>> Hi Mark, >> >> As I said in my previous mail I think we?re going quite well with Jira and ML so >> we can postpone the meeting, except if you have important matters than needs >> synchronous conversation ;). >> >> Antoine >> >> >> >> Le 3 f?vr. 2014 ? 15:52, Mark Struberg a ?crit : >> >>> Hi! >>> >>> Not sure whether freenode is up again in the evening. Where do we meet if >> not? >>> >>> LieGrue, >>> strub >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> From antoine.sabotdurand at gmail.com Mon Feb 3 11:54:00 2014 From: antoine.sabotdurand at gmail.com (antoine.sabotdurand at gmail.com) Date: Mon, 03 Feb 2014 16:54:00 +0000 Subject: [cdi-dev] Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm (Perso) Message-ID: <001a11c36922cd386b04f1835efa@google.com> This event has been changed. Title: CDI 1.2 MR meeting Proposed agenda : - Ready to fix review and assignation - Discussion on other ticket - Progess and obstacles When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm Paris (changed) Where: IRC #jsr346 Channel on Freenode Calendar: Perso Who: (Guest list has been hidden at organizer's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/181e7760/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1585 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/181e7760/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1633 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/181e7760/attachment-0003.bin From antoine.sabotdurand at gmail.com Mon Feb 3 11:55:16 2014 From: antoine.sabotdurand at gmail.com (antoine.sabotdurand at gmail.com) Date: Mon, 03 Feb 2014 16:55:16 +0000 Subject: [cdi-dev] Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm (Perso) Message-ID: This event has been changed. Title: CDI 1.2 MR meeting Proposed agenda : - Ready to fix review and assignation - Discussion on other ticket - Progess and obstacles View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en. (changed) When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 except Mon Feb 3 6pm Paris Where: IRC #jsr346 Channel on Freenode Calendar: Perso Who: (Guest list has been hidden at organizer's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/48ce4c9f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1903 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/48ce4c9f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1955 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140203/48ce4c9f/attachment-0001.bin From issues at jboss.org Tue Feb 4 01:08:28 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Tue, 4 Feb 2014 01:08:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-234) behavior of arrays without @Nonbinding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12941018#comment-12941018 ] Pete Muir commented on CDI-234: ------------------------------- My PR had problems, that's why it wasn't merged. > behavior of arrays without @Nonbinding > -------------------------------------- > > Key: CDI-234 > URL: https://issues.jboss.org/browse/CDI-234 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts > Affects Versions: 1.0 > Reporter: Romain Manni-Bucau > Assignee: Pete Muir > Priority: Minor > Fix For: TBD > > > The spec says: > "Array-valued or annotation-valued members of a qualifier type should be annotated @Nonbinding in a portable application. > If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior > results." > The case of arrays without this annotation should be managed to get a better portability. The equality of arrays is determined through "Arrays" helper (http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/annotation/Annotation.html) so i don't think there is any technical issue to consider arrays as a field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From gunnar at hibernate.org Tue Feb 4 03:54:10 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 4 Feb 2014 09:54:10 +0100 Subject: [cdi-dev] Is it required to explicitly add @Any for custom beans? Message-ID: Hi, I'm registering a custom Bean implementation using a portable extension. Injection of this bean using the @Any qualifier fails unless I explicitly add this qualifier in the getQualifiers() implementation of my bean. Now the spec says in 2.3.1: "Every bean has the built-in qualifier @Any, even if it does not explicitly declare this qualifier [...]" Based on that, I had expected that I'm not required to add this qualifier to my custom bean implementation. Or am I misinterpreting the spec here? Thanks, --Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140204/35d72466/attachment.html From mkouba at redhat.com Tue Feb 4 04:15:48 2014 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 04 Feb 2014 10:15:48 +0100 Subject: [cdi-dev] Is it required to explicitly add @Any for custom beans? In-Reply-To: References: Message-ID: <52F0AFC4.2030506@redhat.com> Hi Gunnar, I believe it is required. See the spec section 11.1 The Bean interface: "getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() must return the bean types, qualifiers, scope type, bean name and stereotypes of the bean, as defined in Chapter 2" I think the sentence you're referencing is rather about class-based beans, not custom beans. But it's not very clear. M Dne 4.2.2014 09:54, Gunnar Morling napsal(a): > Hi, > > I'm registering a custom Bean implementation using a portable extension. > Injection of this bean using the @Any qualifier fails unless I > explicitly add this qualifier in the getQualifiers() implementation of > my bean. > > Now the spec says in 2.3.1: > > "Every bean has the built-in qualifier @Any, even if it does not > explicitly declare this qualifier [...]" > > Based on that, I had expected that I'm not required to add this > qualifier to my custom bean implementation. Or am I misinterpreting the > spec here? > > Thanks, > > --Gunnar > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > From gunnar at hibernate.org Tue Feb 4 06:23:20 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 4 Feb 2014 12:23:20 +0100 Subject: [cdi-dev] Is it required to explicitly add @Any for custom beans? In-Reply-To: <52F0AFC4.2030506@redhat.com> References: <52F0AFC4.2030506@redhat.com> Message-ID: Hi Martin, 2014/2/4 Martin Kouba > Hi Gunnar, > > I believe it is required. > > See the spec section 11.1 The Bean interface: > "getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() > must return the bean types, qualifiers, scope type, bean name and > stereotypes of the bean, as defined in Chapter 2" > > I think the sentence you're referencing is rather about class-based > beans, not custom beans. > Yes, that's the question. It doesn't explicitly say it's about class-based beans only, so it can be perceived as applying to custom beans as well. Then I'd understand the "as defined in Chapter 2" from section 11.1 as "it's not required to explicitly return @Any". > But it's not very clear. > Right, some clarification would be nice. In my particular case I'll just add a literal for @Any, but it's easy to forget to do so when writing a PE, so it might be useful to require a CDI implementation to automatically add that qualifier for custom beans if missing. > > M > > > Dne 4.2.2014 09:54, Gunnar Morling napsal(a): > > Hi, > > > > I'm registering a custom Bean implementation using a portable extension. > > Injection of this bean using the @Any qualifier fails unless I > > explicitly add this qualifier in the getQualifiers() implementation of > > my bean. > > > > Now the spec says in 2.3.1: > > > > "Every bean has the built-in qualifier @Any, even if it does not > > explicitly declare this qualifier [...]" > > > > Based on that, I had expected that I'm not required to add this > > qualifier to my custom bean implementation. Or am I misinterpreting the > > spec here? > > > > Thanks, > > > > --Gunnar > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140204/c8017414/attachment-0001.html From pmuir at redhat.com Tue Feb 4 08:51:04 2014 From: pmuir at redhat.com (Pete Muir) Date: Tue, 4 Feb 2014 19:21:04 +0530 Subject: [cdi-dev] Is it required to explicitly add @Any for custom beans? In-Reply-To: References: <52F0AFC4.2030506@redhat.com> Message-ID: <8C9A9B4D-8977-410C-94B2-B3AAD4A5EFB7@redhat.com> Agreed, we can tidy up the language here. On 4 Feb 2014, at 16:53, Gunnar Morling wrote: > Hi Martin, > > 2014/2/4 Martin Kouba > Hi Gunnar, > > I believe it is required. > > See the spec section 11.1 The Bean interface: > "getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() > must return the bean types, qualifiers, scope type, bean name and > stereotypes of the bean, as defined in Chapter 2" > > I think the sentence you're referencing is rather about class-based > beans, not custom beans. > > Yes, that's the question. > > It doesn't explicitly say it's about class-based beans only, so it can be perceived as applying to custom beans as well. Then I'd understand the "as defined in Chapter 2" from section 11.1 as "it's not required to explicitly return @Any". > > But it's not very clear. > > Right, some clarification would be nice. In my particular case I'll just add a literal for @Any, but it's easy to forget to do so when writing a PE, so it might be useful to require a CDI implementation to automatically add that qualifier for custom beans if missing. > > M > > > Dne 4.2.2014 09:54, Gunnar Morling napsal(a): > > Hi, > > > > I'm registering a custom Bean implementation using a portable extension. > > Injection of this bean using the @Any qualifier fails unless I > > explicitly add this qualifier in the getQualifiers() implementation of > > my bean. > > > > Now the spec says in 2.3.1: > > > > "Every bean has the built-in qualifier @Any, even if it does not > > explicitly declare this qualifier [...]" > > > > Based on that, I had expected that I'm not required to add this > > qualifier to my custom bean implementation. Or am I misinterpreting the > > spec here? > > > > Thanks, > > > > --Gunnar > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From pmuir at redhat.com Wed Feb 5 03:55:15 2014 From: pmuir at redhat.com (Pete Muir) Date: Wed, 5 Feb 2014 08:55:15 +0000 Subject: [cdi-dev] exclude rules questions In-Reply-To: References: <1391198869.91584.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF6629.6000801@redhat.com> <1391422275.25784.YahooMailNeo@web28903.mail.ir2.yahoo.com> <52EF7344.8070900@redhat.com> <1391428943.92189.YahooMailNeo@web28902.mail.ir2.yahoo.com> Message-ID: +1, this was intended to be the Ant/Maven approach, not some other approach entirely. Can we address this in the MR? On 3 Feb 2014, at 12:08, Romain Manni-Bucau wrote: > +1 we should stay as much as possible to java world and not regex one > which always makes things hard to follow...and here it would be pretty > useless > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-03 Mark Struberg : >> If you do a word-by-word interpretation of the spec, then even the .* paragraph would include sub-packages. But that does not make sense from a user perspective! >> >> >> The spec contradicts itself in this regard. And in this case we should pick the option which is most likely the one the user wants. This case will really rarely be hit in the wild though. >> >> Let's look what other established Java mechanism do in this area: >> >> * OSGi: it only knows .* (no .** over there afaik) but while this also covers sub-packages ,foo.* does _not_ cover foobar. >> >> * Maven: knows .* and .**. foo.* does _not_ cover foobar neither >> >> >> Feel free to point me to _important_ Java projects where foobar gets covered by foo.** >> >> >> LieGrue, >> strub >> >> >> >> >>> On Monday, 3 February 2014, 11:45, Martin Kouba wrote: >>>> Dne 3.2.2014 11:11, Mark Struberg napsal(a): >>>> >>>> >>>> >>>> ad 1.) >>>> >>>> Well, I do not entirely agree with the foobar also being excluded. The spec >>> says: >>>> >>>> "" >>>> >>>> "The fourth exclude filter will exclude all classes in the >>> com.acme.ejb package, and any subpackages if the system property exclude-ejbs is >>> set (with any value)." >>>> >>>> Clearly com.acme.ejbrother is neither com.acme.ejb nor a sub-package. >>>> From a user view I'd say it makes no sense to also exclude ejbrother. >>>> >>> >>> Yes. But it's only an example description which indicates it was not >>> intended. >>> >>> IMO the authoritative statement is: >>> "the package name of the type being discovered starts with the value of >>> the name attribute with a suffix ".**" of the exclude filter" >>> >>>> >>>> ad 2.) >>>> >>>> We must clarify whether multiple conditions in a element are >>> OR or AND. >>> >>> I think it's OR because the spec states: >>> "If the exclude filter definition contains: >>> * ...condition, OR >>> then the filter is inactive." >>> >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> >>>>> On Monday, 3 February 2014, 10:49, Martin Kouba >>> wrote: >>>>>> Hi Mark, >>>>> >>>>> Dne 31.1.2014 21:07, Mark Struberg napsal(a): >>>>>> >>>>>> >>>>>> Hi! >>>>>> >>>>>> A few questions regarding exclude rules >>>>>> >>>>>> 1.) does .* mean only the package, but no sub-packages. Whereas >>> .** also >>>>> includes sub-packages? >>>>>> Marek brought up another interesting note: com.foo.** would >>> according to >>>>> the wording also exclude com.foobar... Is that intended? >>>>>> >>>>> >>>>> Yes, types from "com.foobar" would be excluded as well. >>> I'm not >>>>> sure it >>>>> was intended but we should not change the behaviour due to backwards >>>>> compatibility... >>>>> >>>>>> >>>>>> 2.) Are multiple children allowed in an exclude rule in >>> beans.xml? >>>>> >>>>> Yep, check also the schema file (beans_1_1.xsd). >>>>> >>>>>> There is a funny example in the spec: >>>>>> >>>>>> >>>>>> >>>>>> >>>> name="javax.enterprise.inject.Model"/> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> But I could not find the explanation what should happen. The >>>>> if-class-available is nowhere stated. Or did I overlook it? >>>>>> >>>>> >>>>> "if-class-available" is described above the example and in >>> xsd. The >>>>> filter is active only if the classloader for the bean archive CAN >>>>> load a class for that name. So the filter will not be active if the >>>>> "Model" class can't be loaded or if the system property >>>>> "exclude-ejbs" >>>>> is not set. >>>>> >>>>> In any case the description of the example is not complete and we >>> should >>>>> add a TCK test for this as well (AFAIK >>>>> org.jboss.cdi.tck.tests.deployment.exclude.ExcludeFiltersTest is not >>>>> testing multiple child elements). >>>>> >>>>> >>>>>> txs and LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>> >>> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From gunnar at hibernate.org Wed Feb 5 11:00:26 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 5 Feb 2014 17:00:26 +0100 Subject: [cdi-dev] Is it required to explicitly add @Any for custom beans? In-Reply-To: <8C9A9B4D-8977-410C-94B2-B3AAD4A5EFB7@redhat.com> References: <52F0AFC4.2030506@redhat.com> <8C9A9B4D-8977-410C-94B2-B3AAD4A5EFB7@redhat.com> Message-ID: Ok, I've created https://issues.jboss.org/browse/CDI-419 to keep track of it. Thanks, --Gunnar 2014/2/4 Pete Muir > Agreed, we can tidy up the language here. > > On 4 Feb 2014, at 16:53, Gunnar Morling wrote: > > > Hi Martin, > > > > 2014/2/4 Martin Kouba > > Hi Gunnar, > > > > I believe it is required. > > > > See the spec section 11.1 The Bean interface: > > "getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() > > must return the bean types, qualifiers, scope type, bean name and > > stereotypes of the bean, as defined in Chapter 2" > > > > I think the sentence you're referencing is rather about class-based > > beans, not custom beans. > > > > Yes, that's the question. > > > > It doesn't explicitly say it's about class-based beans only, so it can > be perceived as applying to custom beans as well. Then I'd understand the > "as defined in Chapter 2" from section 11.1 as "it's not required to > explicitly return @Any". > > > > But it's not very clear. > > > > Right, some clarification would be nice. In my particular case I'll just > add a literal for @Any, but it's easy to forget to do so when writing a PE, > so it might be useful to require a CDI implementation to automatically add > that qualifier for custom beans if missing. > > > > M > > > > > > Dne 4.2.2014 09:54, Gunnar Morling napsal(a): > > > Hi, > > > > > > I'm registering a custom Bean implementation using a portable > extension. > > > Injection of this bean using the @Any qualifier fails unless I > > > explicitly add this qualifier in the getQualifiers() implementation of > > > my bean. > > > > > > Now the spec says in 2.3.1: > > > > > > "Every bean has the built-in qualifier @Any, even if it does not > > > explicitly declare this qualifier [...]" > > > > > > Based on that, I had expected that I'm not required to add this > > > qualifier to my custom bean implementation. Or am I misinterpreting the > > > spec here? > > > > > > Thanks, > > > > > > --Gunnar > > > > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140205/cc4e168e/attachment.html From issues at jboss.org Wed Feb 5 11:00:29 2014 From: issues at jboss.org (Gunnar Morling (JIRA)) Date: Wed, 5 Feb 2014 11:00:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-419) Clarify whether custom beans need to declare the qualifier "Any" In-Reply-To: References: Message-ID: Gunnar Morling created CDI-419: ---------------------------------- Summary: Clarify whether custom beans need to declare the qualifier "Any" Key: CDI-419 URL: https://issues.jboss.org/browse/CDI-419 Project: CDI Specification Issues Issue Type: Clarification Components: Beans Reporter: Gunnar Morling It's not obvious whether custom beans contributed through a portable extension need to return the {{Any}} qualifier from there {{getQualifier()}} methods or not (the CDI implementation would be required to add it if missing then). Concerned spec sections are: Section 2.3.1: {quote} Every bean has the built-in qualifier @Any, even if it does not explicitly declare this qualifier ... {quote} And section 11.1 which says: {quote} getTypes(), getQualifiers(), getScope(), getName() and getStereotypes() must return the bean types, qualifiers, scope type, bean name and stereotypes of the bean, as defined in Chapter 2 {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:34:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 5 Feb 2014 11:34:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-331) Instance.iterator() shouldn't include non-alternatives that haven't been replaced In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-331: ------------------------------------- Fix Version/s: 1.2 Proposed (was: TBD) > Instance.iterator() shouldn't include non-alternatives that haven't been replaced > --------------------------------------------------------------------------------- > > Key: CDI-331 > URL: https://issues.jboss.org/browse/CDI-331 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.1.PRD > Reporter: Jozef Hartinger > Assignee: Pete Muir > Fix For: 1.2 Proposed > > > The specification currently says that: > {quote} > The iterator() method must: > ? Identify the set of beans that have the required type and required qualifiers and are eligible for injection into the class into > which the parent Instance was injected, according to the rules of typesafe resolution, as defined in Section 5.2.1. > {quote} > The ambiguity resolution algorithm as defined in 5.2.2 should be applied. > This is explicitly required for get() but is not required for iterator(). This causes the following inconsistency: > Assume two classes Foo and Bar which both implement common interface Common. Bar is an enabled alternative. > Assume further the following > {noformat} > @Inject @Any Instance instance > {noformat} > injection point. > It is clear that instance.get() returns Bar. > It is however not clear whether instance.iterator() iterates over: > a) Bar > b) Foo, Bar > and whether instance.isAmbiguous() returns: > a) true > b) false -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:52:28 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 5 Feb 2014 11:52:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected' In-Reply-To: References: Message-ID: Mark Struberg created CDI-420: --------------------------------- Summary: add a bean-discovery-mode 'detected' Key: CDI-420 URL: https://issues.jboss.org/browse/CDI-420 Project: CDI Specification Issues Issue Type: Bug Components: Packaging and Deployment Affects Versions: TBD Reporter: Mark Struberg This is for some future CDI release. We currently only have 3 bean-discovery-modes * none * all * annotated The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for ? each Java class, interface or enum deployed in an explicit bean archive, and ? each Java class with a bean defining annotation in an implicit bean archive. ? each session bean Which means that we do not get the ProcessAnnotatedType event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if the (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the processing. I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 11:52:28 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 5 Feb 2014 11:52:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated CDI-420: ------------------------------ Description: This is for some future CDI release. We currently only have 3 bean-discovery-modes * none * all * annotated The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for ? each Java class, interface or enum deployed in an explicit bean archive, and ? each Java class with a bean defining annotation in an implicit bean archive. ? each session bean Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... was: This is for some future CDI release. We currently only have 3 bean-discovery-modes * none * all * annotated The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for ? each Java class, interface or enum deployed in an explicit bean archive, and ? each Java class with a bean defining annotation in an implicit bean archive. ? each session bean Which means that we do not get the ProcessAnnotatedType event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if the (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the processing. I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... > add a bean-discovery-mode 'detected' > ------------------------------------ > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 5 19:18:28 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 5 Feb 2014 19:18:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-420) add a bean-discovery-mode 'detected' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12941690#comment-12941690 ] Mark Struberg commented on CDI-420: ----------------------------------- It's also not clear to me whether a mode 'annotated' should find interfaces and fire a ProcessAnnotatedType for them? > add a bean-discovery-mode 'detected' > ------------------------------------ > > Key: CDI-420 > URL: https://issues.jboss.org/browse/CDI-420 > Project: CDI Specification Issues > Issue Type: Bug > Components: Packaging and Deployment > Affects Versions: TBD > Reporter: Mark Struberg > > This is for some future CDI release. > We currently only have 3 bean-discovery-modes > * none > * all > * annotated > The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for > ? each Java class, interface or enum deployed in an explicit bean archive, and > ? each Java class with a bean defining annotation in an implicit bean archive. > ? each session bean > Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation. > It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing. > I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 08:50:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Feb 2014 08:50:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-413 started by Antoine Sabot-Durand. > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 08:58:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Feb 2014 08:58:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-413 stopped by Antoine Sabot-Durand. > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 09:02:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Feb 2014 09:02:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-413: ------------------------------------- Issue Type: Bug (was: Clarification) > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 7 09:06:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Feb 2014 09:06:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-413: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/199 Integrated dual licensing in 2 different asciidoc file. Added a maven build to generate documentation in html + docbook + pdf and a maven profile "redhat" to generate doc with asl2 license. The default generation include JCP license > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Fri Feb 7 09:10:32 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 7 Feb 2014 15:10:32 +0100 Subject: [cdi-dev] Please review PR 199 Message-ID: I corrected CDI-413 [1] and included dual licensing and doc generation with Asciidoctor maven plugin and JDocbook plugin. Please review and test PR 199 [2] Antoine [1]https://issues.jboss.org/browse/CDI-413 [2]https://github.com/cdi-spec/cdi/pull/199 From issues at jboss.org Fri Feb 7 11:02:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 7 Feb 2014 11:02:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-410: ---------------------------------------- Assignee: Antoine Sabot-Durand > @RequestScoped Javadoc outdated > ------------------------------- > > Key: CDI-410 > URL: https://issues.jboss.org/browse/CDI-410 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 04:23:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 04:23:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-410 started by Antoine Sabot-Durand. > @RequestScoped Javadoc outdated > ------------------------------- > > Key: CDI-410 > URL: https://issues.jboss.org/browse/CDI-410 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 13:53:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 13:53:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-410. -------------------------------------- Resolution: Done > @RequestScoped Javadoc outdated > ------------------------------- > > Key: CDI-410 > URL: https://issues.jboss.org/browse/CDI-410 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 16:09:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 16:09:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-413: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/200 (was: https://github.com/cdi-spec/cdi/pull/199) > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 16:11:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 16:11:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-413. -------------------------------------- Resolution: Done please review https://github.com/cdi-spec/cdi/pull/200 > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 16:19:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 16:19:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-410: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/201 Please review https://github.com/cdi-spec/cdi/pull/201 > @RequestScoped Javadoc outdated > ------------------------------- > > Key: CDI-410 > URL: https://issues.jboss.org/browse/CDI-410 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 17:45:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 17:45:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of Request Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-381: ---------------------------------------- Assignee: Antoine Sabot-Durand > Additional implementations of Request Context > --------------------------------------------- > > Key: CDI-381 > URL: https://issues.jboss.org/browse/CDI-381 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Suppose another spec wanted to define when @RequestScoped applied to its > operations, how would it do that? The javadocs for @RequestScoped seem to > be an exhaustive list, not allowing the scope to be used in other contexts. > The javadocs need to indicate that the scope can be active at other > times beyond what the spec describes. It can be tricky to do that in a > way that doesn't allow people to implement the currently defined scopes > incorrectly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 8 17:47:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Sat, 8 Feb 2014 17:47:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-405: ---------------------------------------- Assignee: Antoine Sabot-Durand > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 06:43:28 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 10 Feb 2014 06:43:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12942951#comment-12942951 ] Martin Kouba commented on CDI-382: ---------------------------------- [~struberg] by the way the spec does use the original wording for decorators, see chapter 8: {quote} Decorators are not applied to the return value of a producer method or the current value of a producer field. {quote} > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 10 12:51:28 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Mon, 10 Feb 2014 12:51:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12943151#comment-12943151 ] Pete Muir commented on CDI-382: ------------------------------- Agreed with [~struberg], I would have said something like "no additional interceptors are added to the return value, other than any already applied to injected objects or any added manually". But that is very poorly worded, ideally we would reduce this sentence to have no conjunctions that express additional conditions. > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From mkouba at redhat.com Thu Feb 13 04:46:07 2014 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 13 Feb 2014 10:46:07 +0100 Subject: [cdi-dev] CDI TCK 1.1.3.Final Message-ID: <52FC945F.2060304@redhat.com> Hello everyone, we've just released CDI TCK 1.1.3.Final - the third bugfix version for CDI 1.1. The artifacts are available in Maven central and the dist zip on sourceforge.net [1]. Note that the exclude list in canonical TestNG config file [2] is clean now. See also the list of resolved issues: https://issues.jboss.org/issues/?jql=fixVersion%20%3D%20%221.1.3.Final%22%20AND%20project%20%3D%20CDITCK Martin [1] https://sourceforge.net/projects/jboss/files/CDI-TCK/1.1.3.Final/ [2] https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/resources/tck-tests.xml -- Martin Kouba JBoss Quality Assurance Engineer CDI TCK lead Red Hat, Czech Republic From antoine at sabot-durand.net Thu Feb 13 07:38:19 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 13 Feb 2014 13:38:19 +0100 Subject: [cdi-dev] thoughts about CDI-377 Message-ID: <46CA1340-BD6B-4456-A11C-3FA392D9725E@sabot-durand.net> Hi all, Yesterday someone asked me why he couldn?t deploy hawtio [1] in Wildfly without having a crash full of weld exceptions. He couldn?t understand why he was having CDI related error on an app that contains no CDI stuff. I orientated him to Wildfly settings[2] to indicate how he could turn off implicite Bean Archive. I also had to tell him that he should do something else if he want the app to turn on Glassfish and something else when it?ll be deployed on the future Java EE 7 TomEE version. One of the implicit jar in the hawtio.war that triggers CDI and thus make the app crash (thanks to CDI-377) is 'sisu-inject-plexus-2.3.4.jar? coming from sonatype plexus framework I guess. First time I see this dependency... Right now the idea to solve CDI-377 is to add exclusion list at the implementation level. But I?m quite sure that 'sisu-inject-plexus-2.3.4.jar? would be forgot on such a list as lot of other libs. So for me this approach is flawed and totally useless. It?s a non sense to have to maintain a list of all lib including JSR 330 annotation that are not CDI ! I really think we should provide a solution at spec level for CDI-377. Right now I have 2 suggestion : 1) Revert back default bean discovery type to ?none? It?ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It?ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. Perosnaly I think it?s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn?t intend to use. 2) Provide new propagation attribute on bean element in beans.xml so when I put it would propagate the ? none ? to all bean archive without beans.xml I guess this solution is harder to implement and that it is not working for EAR packaging so that?s not my favorite. Thanks for your feedback on that. Antoine [1] http://hawt.io [2] https://docs.jboss.org/author/display/WFLY8/CDI+Reference From rmannibucau at gmail.com Thu Feb 13 07:50:32 2014 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Thu, 13 Feb 2014 13:50:32 +0100 Subject: [cdi-dev] thoughts about CDI-377 In-Reply-To: <46CA1340-BD6B-4456-A11C-3FA392D9725E@sabot-durand.net> References: <46CA1340-BD6B-4456-A11C-3FA392D9725E@sabot-durand.net> Message-ID: Hi Antoine, It is surely better to activate CDI on demand for sure but I think we should be able to configure (using a shared spec across EE) jar to include/exclude in scanning (jar names and not packages). Propagate solution seems something hard to maintain/use in real life IMHO. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-13 13:38 GMT+01:00 Antoine Sabot-Durand : > Hi all, > > > Yesterday someone asked me why he couldn't deploy hawtio [1] in Wildfly without having a crash full of weld exceptions. He couldn't understand why he was having CDI related error on an app that contains no CDI stuff. I orientated him to Wildfly settings[2] to indicate how he could turn off implicite Bean Archive. I also had to tell him that he should do something else if he want the app to turn on Glassfish and something else when it'll be deployed on the future Java EE 7 TomEE version. > > One of the implicit jar in the hawtio.war that triggers CDI and thus make the app crash (thanks to CDI-377) is 'sisu-inject-plexus-2.3.4.jar' coming from sonatype plexus framework I guess. First time I see this dependency... > > Right now the idea to solve CDI-377 is to add exclusion list at the implementation level. But I'm quite sure that 'sisu-inject-plexus-2.3.4.jar' would be forgot on such a list as lot of other libs. So for me this approach is flawed and totally useless. It's a non sense to have to maintain a list of all lib including JSR 330 annotation that are not CDI ! > > I really think we should provide a solution at spec level for CDI-377. > > Right now I have 2 suggestion : > > 1) Revert back default bean discovery type to 'none' > It'll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It'll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). > The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. Perosnaly I think it's better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn't intend to use. > > > 2) Provide new propagation attribute on bean element in beans.xml > so when I put > > it would propagate the << none >> to all bean archive without beans.xml > I guess this solution is harder to implement and that it is not working for EAR packaging so that's not my favorite. > > Thanks for your feedback on that. > > Antoine > > > [1] http://hawt.io > [2] https://docs.jboss.org/author/display/WFLY8/CDI+Reference > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From antoine at sabot-durand.net Thu Feb 13 07:54:38 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 13 Feb 2014 13:54:38 +0100 Subject: [cdi-dev] Monday meeting minutes Message-ID: Hi all, Forgot to post meeting minutes [1] and full log [2]. you??l find the minutes below as well ====================== =============== #jsr346 Meeting =============== Meeting started by antoine_sd at 16:51:58 UTC. The full logs are available at http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-02-10-16.51.log.html . Meeting summary --------------- * Ready to fix review and assignation (antoine_sd, 16:52:14) * LINK: https://issues.jboss.org/issues/?filter=12320805 (antoine_sd, 16:52:55) * waiting PR (antoine_sd, 16:54:53) * LINK: https://github.com/cdi-spec/cdi/pull/200 (antoine_sd, 16:56:12) * AGREED: review policy is : at least review from the impl team + one other (antoine_sd, 17:00:49) * implementing team is jharting, mkouba, struberg and arne (antoine_sd, 17:11:48) * ACTION: create a ticket to tranform project in full maven one (antoine_sd, 17:20:42) * Progess and obstacles (antoine_sd, 17:21:00) Meeting ended at 17:41:12 UTC. Action Items ------------ * create a ticket to tranform project in full maven one Action Items, by person ----------------------- * **UNASSIGNED** * create a ticket to tranform project in full maven one ====================== Unassigned point at the end is mine ;) Antoine [1] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-02-10-16.51.html [2] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346.2014-02-10-16.51.log.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140213/4d8dc2f1/attachment.html From issues at jboss.org Thu Feb 13 08:03:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 08:03:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944229#comment-12944229 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ I really think we should provide a solution at spec level for CDI-377. For me the best solution is to change default bean discovery type to ?none? It?ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It?ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it?s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn?t intend to use. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Thu Feb 13 08:05:53 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 13 Feb 2014 14:05:53 +0100 Subject: [cdi-dev] thoughts about CDI-377 In-Reply-To: References: <46CA1340-BD6B-4456-A11C-3FA392D9725E@sabot-durand.net> Message-ID: Hi Romain, Thanks for your answer. I agree with you on the Java EE wide approach, but I was thinking on a solution in our reach for 1.2 ;). Yeah propagate trick looks very hazardous. I really think we should revert to explicit CDI activation. I put a shorter version of my mail on the ticket comment to continue discussion. Antoine Le 13 f?vr. 2014 ? 13:50, Romain Manni-Bucau a ?crit : > Hi Antoine, > > It is surely better to activate CDI on demand for sure but I think we > should be able to configure (using a shared spec across EE) jar to > include/exclude in scanning (jar names and not packages). > > Propagate solution seems something hard to maintain/use in real life IMHO. > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2014-02-13 13:38 GMT+01:00 Antoine Sabot-Durand : >> Hi all, >> >> >> Yesterday someone asked me why he couldn't deploy hawtio [1] in Wildfly without having a crash full of weld exceptions. He couldn't understand why he was having CDI related error on an app that contains no CDI stuff. I orientated him to Wildfly settings[2] to indicate how he could turn off implicite Bean Archive. I also had to tell him that he should do something else if he want the app to turn on Glassfish and something else when it'll be deployed on the future Java EE 7 TomEE version. >> >> One of the implicit jar in the hawtio.war that triggers CDI and thus make the app crash (thanks to CDI-377) is 'sisu-inject-plexus-2.3.4.jar' coming from sonatype plexus framework I guess. First time I see this dependency... >> >> Right now the idea to solve CDI-377 is to add exclusion list at the implementation level. But I'm quite sure that 'sisu-inject-plexus-2.3.4.jar' would be forgot on such a list as lot of other libs. So for me this approach is flawed and totally useless. It's a non sense to have to maintain a list of all lib including JSR 330 annotation that are not CDI ! >> >> I really think we should provide a solution at spec level for CDI-377. >> >> Right now I have 2 suggestion : >> >> 1) Revert back default bean discovery type to 'none' >> It'll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It'll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). >> The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. Perosnaly I think it's better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn't intend to use. >> >> >> 2) Provide new propagation attribute on bean element in beans.xml >> so when I put >> >> it would propagate the << none >> to all bean archive without beans.xml >> I guess this solution is harder to implement and that it is not working for EAR packaging so that's not my favorite. >> >> Thanks for your feedback on that. >> >> Antoine >> >> >> [1] http://hawt.io >> [2] https://docs.jboss.org/author/display/WFLY8/CDI+Reference >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev From issues at jboss.org Thu Feb 13 08:07:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 08:07:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944229#comment-12944229 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/13/14 8:06 AM: ------------------------------------------------------------------- I really think we should provide a solution at spec level for CDI-377. For me the best solution is to change default bean discovery type to ?none? It?ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It?ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that they cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it?s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn?t intend to use. was (Author: antoinesabot-durand): I really think we should provide a solution at spec level for CDI-377. For me the best solution is to change default bean discovery type to ?none? It?ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It?ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it?s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn?t intend to use. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 08:11:28 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 13 Feb 2014 08:11:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944232#comment-12944232 ] Jozef Hartinger commented on CDI-377: ------------------------------------- If we change the default bean discovery mode to ?none? then we break compatibility with existing CDI 1.1 applications. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 08:25:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 08:25:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944239#comment-12944239 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ Yes we do. But we broke compatibility with the rest of the world with CDI 1.1. Today people who are taking their app containing JSR 330 application to Wildfly see their app crash with a stuff they don't use in their devs. I don't think it's a great promotion of CDI ;). WDYT [~jharting] ? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 08:53:29 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 13 Feb 2014 08:53:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944250#comment-12944250 ] Jozef Hartinger commented on CDI-377: ------------------------------------- This is not how Java EE works. You have to retain backwards compatibility. You can define what was previously optional or undefined (e.g. implicit bean archive support in CDI 1.0) but you cannot change defined behavior. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 09:09:30 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 13 Feb 2014 09:09:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944266#comment-12944266 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- @Jozef: so we should really rollback it since that's what was done between 1.0 and 1.1 and it creates a lot of issues in apps. For JavaEE this is a clear BUG + CDi 1.1 is not yet really used so we should do it now IMHO. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 09:25:29 2014 From: issues at jboss.org (Joe Bergmark (JIRA)) Date: Thu, 13 Feb 2014 09:25:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944279#comment-12944279 ] Joe Bergmark commented on CDI-377: ---------------------------------- I completely agree with Jozef. I don't see how we break apps written using the rules that were explicit in CDI 1.1, especially in what is supposed to be a MR of CDI 1.1. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 09:29:29 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 13 Feb 2014 09:29:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944281#comment-12944281 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- We scan more than before and it is enough to break apps not relying on CDI rules. Explicit declaration should be at least the default to keep compatibility. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 10:09:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 10:09:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944309#comment-12944309 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ [~jharting] I understand what you're saying but I don't agree. That's what I'd call a general guidelines, but when we decided something wrong (a mistake that we didn't foreseen) we have to do something. And we already broke this rule by reverting things in CDI-389. We have the opportunity to correct an issue before mainstream developer start seriously using CDI 1.1+. Sorry to say that but there are zillions of Spring and Guice libs out there with dev team that don't care about CDI and that will have no reason or interest to add a beans.xml file to their lib. This critical ticket is 9 months old with no satisfying solution. At this step I think nobody can comme in the discussion and simply say "no" without a constructive solution. So what do you suggest to fix this? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 10:13:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 10:13:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944311#comment-12944311 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ [~bergmark]The problem is that we break apps that don't use CDI. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Thu Feb 13 10:26:53 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 13 Feb 2014 16:26:53 +0100 Subject: [cdi-dev] I need implementation team review on PR 201 Message-ID: <5F744205-7369-420D-9735-80803403F87F@sabot-durand.net> Hi, As defined on the last meeting I need the review of one member of the implementor team (Arne, Jozef, Mark or Martin) on PR 201[1] to close the ticket CDI-410. It should be quick. thanks Antoine [1]https://github.com/cdi-spec/cdi/pull/201 From issues at jboss.org Thu Feb 13 10:57:29 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Thu, 13 Feb 2014 10:57:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944334#comment-12944334 ] Jozef Hartinger commented on CDI-377: ------------------------------------- We definitely cannot revert one of the main new features of CDI 1.1 just because we think that CDI 1.1 is not mainstream yet. Btw, how is your proposal consistent with Java EE 7 spec which says that CDI is enabled by default in EE7? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:03:29 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Thu, 13 Feb 2014 11:03:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944339#comment-12944339 ] John Ament commented on CDI-377: -------------------------------- As a user, I find this bug tough to swallow. On one side, what I think the Java EE platform is saying is that if you run on an EE container, you're getting EE features. In the case of what was added in EE7, this means you get various stuff automatically added to your app, including a servlet container, a default JMS connection factory, JAX-RS enabled, JSF enabled and CDI enabled. The problem is that CDI enabling means enabling of JSR-330 annotation processing. This means for apps using Spring, Guice that there's already a consumer of the JSR-330 annotations on the path and if they want to be used they need a way to coexist with the CDI processors. The downside to this is that now you need to have certain libraries being EE aware, that when they run on an EE7 container they need to follow certain rules. I'm not sure if this is the original intention of the EE expert group, it may be worthwhile to ask. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:17:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 11:17:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944344#comment-12944344 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ [~jharting] I perfectly understood you were against that idea the first time. Now what do you suggest except crappy filtering and status quo ? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:19:29 2014 From: issues at jboss.org (Jens Schumann (JIRA)) Date: Thu, 13 Feb 2014 11:19:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944347#comment-12944347 ] Jens Schumann commented on CDI-377: ----------------------------------- Shouldn't we move the discussion to the mailing list first? IMHO the problems related to automatic annotation processing gained a political dimension already because (in the community well-recognized) people claim that CDI 1.1 s***s due to the fact that it breaks existing application deployments. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:25:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 11:25:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944351#comment-12944351 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ The other obvious solution I see is too remove {{@Singleton}} from the list of Bean defining annotations. As CDI doesn't really support it, it wouldn't be too harmful for existing CDI app. It would fix the problem since all beans in Spring or Guice libs that triggers CDI does it with this annotation. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:25:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 11:25:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944351#comment-12944351 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/13/14 11:24 AM: -------------------------------------------------------------------- The other obvious solution I see is to remove {{@Singleton}} from the list of Bean defining annotations. As CDI doesn't really support it, it wouldn't be too harmful for existing CDI app. It would fix the problem since all beans in Spring or Guice libs that triggers CDI does it with this annotation. was (Author: antoinesabot-durand): The other obvious solution I see is too remove {{@Singleton}} from the list of Bean defining annotations. As CDI doesn't really support it, it wouldn't be too harmful for existing CDI app. It would fix the problem since all beans in Spring or Guice libs that triggers CDI does it with this annotation. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:27:29 2014 From: issues at jboss.org (Jens Schumann (JIRA)) Date: Thu, 13 Feb 2014 11:27:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944355#comment-12944355 ] Jens Schumann commented on CDI-377: ----------------------------------- Sehr geehrte Damen und Herren, vom 12.02.2013-14.02.2013 bin ich aufgrund eines Workshops nur eingeschr?nkt zu erreichen. In dringenden F?llen wenden Sie sich bitte an unser Sekretariat (sekretariat at openknowledge.de) unter der Nummer +49 441 4082 0. E-Mails werden nicht weiter geleitet. Mit freundlichen Gr??en, Jens Schumann ----------------------------------------------------------------------------- Dear Sir or Madam, I'm out of office from February 12th to 14th. For anything urgent please contact our office management (sekretariat at openknowledge.de) at +49 441 4082 0. Mails will not be forwarded. Sincerely, Jens Schumann > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:37:29 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 13 Feb 2014 11:37:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944360#comment-12944360 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- @Antoine: remove @Singleton, @Named, @Inject...all have side effects on CDI so the more comprehensive is to be able to not scan spring/guice/other libs/code. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 11:59:28 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 13 Feb 2014 11:59:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944367#comment-12944367 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ @Romain according to section 2.5 CDI scopes are bean defining annotations. Its not the case of @named, @inject, etc.. The only scope that is common to CDI and JSR 330 is {{@Singleton}}. This is the presence of this scope on Guice or Spring Beans that triggers CDI thanks to annotated discovery mode. As CDI hardly supports {{@Singleton}} (not a mention in the spec and warning to not use in RI doc) we could imagine to exclude it from the list of Bean defining annotations. That wouldn't mean we don't support it that would mean that class annotated with {{@Singleton}} won't transform the archive in implicit bean archive. It can still be taken as such by adding a {{@Dependent}} or {{@ApplicationScoped}} somewhere or making the archive explicit by putting a beans.xml in it. We can explain in the spec that we excluded it to assure compatibility with other JSR 330 framework : making CDI friendly and not s***ing solution. WDYT ? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 13 12:09:29 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Thu, 13 Feb 2014 12:09:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944370#comment-12944370 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- @Inject is still an issue since it can bring ambiguous stuff etc if used in spring/guice etc. I saw it several times. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 02:25:29 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 14 Feb 2014 02:25:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944503#comment-12944503 ] Jozef Hartinger commented on CDI-377: ------------------------------------- {quote}@Inject is still an issue since it can bring ambiguous stuff etc if used in spring/guice etc. I saw it several times.{quote} No it is not. These are only triggered by a @Singleton or some other scope. If these are not recognized, @Inject itself does not harm. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 02:43:29 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 14 Feb 2014 02:43:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944508#comment-12944508 ] Jozef Hartinger commented on CDI-377: ------------------------------------- {quote}The other obvious solution I see is to remove @Singleton from the list of Bean defining annotations. As CDI doesn't really support it, it wouldn't be too harmful for existing CDI app. It would fix the problem since all beans in Spring or Guice libs that triggers CDI does it with this annotation.{quote} This is much better than the previous solution. I can see these options: # To introduce a no-bean-archive marker file (e.g. no-beans.xml). This solution: #* is backwards compatible #* only solves the problem for libraries that care and only in new or repackaged versions of the lib # Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is: #* similar to your recent proposal #* probably trickier to define nicely #* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes) > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 02:51:28 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 14 Feb 2014 02:51:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944511#comment-12944511 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- 1. no-beans.xml wouldn't work since when you dev for a servlet container you don't care then when you are deployd in a EE containet you don't want to repackage. 2. would mean you can't write cdi code with @Singleton (so excluding it would be better) and makes understanding of issues harder Maybe we could veto a module (abstraction for jar, classes dir ...) before scanning it? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 03:09:29 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Fri, 14 Feb 2014 03:09:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944519#comment-12944519 ] Jozef Hartinger commented on CDI-377: ------------------------------------- {quote}1. no-beans.xml wouldn't work since when you dev for a servlet container you don't care then when you are deployd in a EE containet you don't want to repackage.{quote} Right, this would be helpful only if the library authors care. This may not be the entire solution of the problem but may be part of it. The important point here is that even if we get rid of @Singleton support, there would still be no portable way (across CDI 1.0, 1.1 and 1.2) of saying that this archive with CDI scopes is not intended to be a bean archive (i.e. bean-discovery-mode="none"). {quote}2. would mean you can't write cdi code with @Singleton (so excluding it would be better) and makes understanding of issues harder{quote} You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it. {quote}Maybe we could veto a module (abstraction for jar, classes dir ...) before scanning it?{quote} To me this sounds way out of scope for a maintenance release. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 03:41:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 14 Feb 2014 03:41:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944528#comment-12944528 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ {quote} You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it. {quote} I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the present jars. {quote} # Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is: #* similar to your recent proposal #* probably trickier to define nicely #* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes) {quote} And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 03:41:30 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 14 Feb 2014 03:41:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944528#comment-12944528 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/14/14 3:40 AM: ------------------------------------------------------------------- {quote} You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it. {quote} I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the including archive. {quote} # Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is: #* similar to your recent proposal #* probably trickier to define nicely #* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes) {quote} And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small. was (Author: antoinesabot-durand): {quote} You can write CDI code in @Singletons as long as your archive also has something else than singletons in it. Agreed that this is more complicated than just getting rid of @Singleton. On the other hand, all CDI implementations are also supposed to implement CDI-330 so I am no sure if we can just get rid of it. {quote} I agree [~jharting]. We have to support all JSR-330 (including {{@singleton}}) but specify that {{@singleton}} *alone* cannot trigger implicit CDI discovery for the present jars. {quote} # Deal with @Singleton somehow. For instance, we could keep @Singleton a bean defining annotation but say that out of the bean defining annotations used in a bean archive, at least one has to be a normal scope or a built-in scope for the bean archive to be recognized. That way we would still be picking up @Singletons as long as they are used together with pure CDI scopes. If there are only @Singletons or non-normal non-builtin scopes in the archive, it will not be recognized. This solution is: #* similar to your recent proposal #* probably trickier to define nicely #* backwards incompatible, but the class of applications possibly affected by this is very small (basically only the apps using only @Singleton or non-normal non-builtin scopes) {quote} And saying that you forgot all CDI apps that are using {{@Singleton}} only but have explicit CDI activation thru {{beans.xml}} file. It makes the number of impacted apps very small. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 04:33:29 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 14 Feb 2014 04:33:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944547#comment-12944547 ] Mark Struberg commented on CDI-408: ----------------------------------- Please note that the following things also do not get discovered right now: * Interfaces - this is often used by Extensions * static Producer methods. Usually the Classes containing these producer methods do not have a CDI Scope... > bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans > --------------------------------------------------------------------------- > > Key: CDI-408 > URL: https://issues.jboss.org/browse/CDI-408 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Reporter: Jens Schumann > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly. > However there are two impacts: > 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere. > 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere. > I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier. > If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD. > -- > [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;) > > Btw: Which JIRA version is CDI 1.1 Final? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 08:17:30 2014 From: issues at jboss.org (Pete Muir (JIRA)) Date: Fri, 14 Feb 2014 08:17:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944656#comment-12944656 ] Pete Muir commented on CDI-377: ------------------------------- If it is just @Singleton that causes the problem, then we should definitely exclude it. We really recommend people NOT to use it in CDI apps anyway... > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 08:49:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 14 Feb 2014 08:49:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944676#comment-12944676 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ [~petemuir] ok. I will investigate to make sure there are no side effect. Apparently some of us (like [~rmannibucau]) have warnings about it. We'll continue to discuss about this lead in the coming weeks before taking a final decision. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 08:53:28 2014 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Fri, 14 Feb 2014 08:53:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944680#comment-12944680 ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- @Antoine: if we can't manage to exclude modules skipping @Singleton would be ok for me too (short term, it would handle majority of cases) but we need to handle it next time for sure > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 08:55:30 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 14 Feb 2014 08:55:30 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944683#comment-12944683 ] Martin Kouba commented on CDI-377: ---------------------------------- What about other scope annotations annotated with {{javax.inject.Scope}}? bq. Any scope type is a bean defining annotation. E.g. if any DI framework built upon JSR 330 defines its own scope type it's a bean defining annotation according to CDI 1.1. Am I right? > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 14 09:31:29 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 14 Feb 2014 09:31:29 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12944710#comment-12944710 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ Good point Martin. I guess we need to also exclude all scopes annotated with {{@javax.inject.scope}} except {{@Dependent}} and keep all scopes annotated with {{@NormalScope}} in bean defining annotations list. Again that doesn't mean we exclude these scope that means they cannot triggers implicit CDI for archive alone. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 08:29:48 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 17 Feb 2014 08:29:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-318 started by Martin Kouba. > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Martin Kouba > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 08:29:48 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 17 Feb 2014 08:29:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945197#comment-12945197 ] Martin Kouba commented on CDI-318: ---------------------------------- PR sent: https://github.com/cdi-spec/cdi/pull/202 > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Martin Kouba > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 08:31:47 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 17 Feb 2014 08:31:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-382 started by Martin Kouba. > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 08:47:47 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 17 Feb 2014 08:47:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945207#comment-12945207 ] Martin Kouba commented on CDI-382: ---------------------------------- [~struberg], [~pmuir], [~arnelim] my final suggestion: *"Interceptor bindings declared on a producer method are not used to associate interceptors with the return value of the producer method."*. The Interceptors spec. says: bq. Interceptor bindings are intermediate annotations that may be used to associate interceptors with any component that is not itself an interceptor. So I believe we should only clarify the purpose of the interceptor bindings declared on a producer. > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 09:59:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 09:59:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945256#comment-12945256 ] Antoine Sabot-Durand commented on CDI-382: ------------------------------------------ ok for me > Clarify interceptors are not associated with the result of a producer method/field > ---------------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 10:19:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 10:19:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-421: ---------------------------------------- Summary: Organize the project as a Maven project with modules Key: CDI-421 URL: https://issues.jboss.org/browse/CDI-421 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Reporter: Antoine Sabot-Durand Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 11:17:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 11:17:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945292#comment-12945292 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ To sum up regarding {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 11:17:49 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 11:17:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945292#comment-12945292 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/17/14 11:16 AM: -------------------------------------------------------------------- To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. was (Author: antoinesabot-durand): To sum up regarding {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 11:17:50 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 11:17:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945292#comment-12945292 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/17/14 11:17 AM: -------------------------------------------------------------------- To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. was (Author: antoinesabot-durand): To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as bean. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 17 11:19:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 17 Feb 2014 11:19:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945292#comment-12945292 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/17/14 11:18 AM: -------------------------------------------------------------------- To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any CDI Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. was (Author: antoinesabot-durand): To sum up my understanding of {{@Singleton}} and other {{@Scope}} management, we have 3 options. # *Stop supporting them in CDI* Not possible IMO due to JSR 330 support and other bad side effects ({{@Dependent}} is annotated with {{@Scope}}) # *Remove them from the list of bean defining annotations list* So by default ({{annotated}} bean-discovery-mode) classes with these Annotation wouldn't be considered as beans. {{@Dependent}} should be an exception. They would always be beans in {{all}} bean-discovery-mode. Perhaps the more consistent approach regarding mixing CDI and other JSR-330 beans in the same archive : allow me to have my Guice beans with {{@Singleton}} and CDI beans with CDI scopes living together. # *Remove them from the list of bean defining annotations list unless one or more classes in the same archive are annotated with a {{@Dependent}} or any Normal Scope annotation* In this case they wouldn't make their archive an implicit bean archive when they are alone. In the case of mixing JSR-330 beans and CDI beans the dev would have to explicitly put a {{@Vetoed}} on non CDI beans to avoid CDI treating them. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:11:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:11:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-318. -------------------------------------- Resolution: Done PR 202 merged > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Martin Kouba > Priority: Minor > Labels: CDI_api_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:17:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:17:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-421: ------------------------------------- Fix Version/s: 1.2 Proposed > Organize the project as a Maven project with modules > ---------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:19:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:19:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12945661#comment-12945661 ] Antoine Sabot-Durand commented on CDI-421: ------------------------------------------ We should also integrate properties and resource filtering for Ref from Javadoc to spec. Like it was done in CDI-318 > Organize the project as a Maven project with modules > ---------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:29:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:29:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-421: ------------------------------------- Labels: Ready_to_fix (was: ) > Organize the project as a Maven project with modules > ---------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:29:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:29:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-418: ------------------------------------- Fix Version/s: 1.2 Proposed > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:31:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:31:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-418: ------------------------------------- Labels: Ready_to_fix (was: ) > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:31:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:31:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-418: ---------------------------------------- Assignee: Antoine Sabot-Durand > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:31:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:31:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-421: ---------------------------------------- Assignee: Antoine Sabot-Durand > Organize the project as a Maven project with modules > ---------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:37:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-399) Make cdi-api an OSGi bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-399: ------------------------------------- Labels: Ready_to_fix (was: ) > Make cdi-api an OSGi bundle > --------------------------- > > Key: CDI-399 > URL: https://issues.jboss.org/browse/CDI-399 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Labels: Ready_to_fix > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:37:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-399) Make cdi-api an OSGi bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-399: ------------------------------------- Fix Version/s: 1.2 Proposed > Make cdi-api an OSGi bundle > --------------------------- > > Key: CDI-399 > URL: https://issues.jboss.org/browse/CDI-399 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:37:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-399) Make cdi-api an OSGi bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-399: ------------------------------------- Assignee: Jozef Hartinger > Make cdi-api an OSGi bundle > --------------------------- > > Key: CDI-399 > URL: https://issues.jboss.org/browse/CDI-399 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:39:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:39:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-399) Make cdi-api an OSGi bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-399: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/196 Jozef sent a PR months ago with this fix. https://github.com/cdi-spec/cdi/pull/196 > Make cdi-api an OSGi bundle > --------------------------- > > Key: CDI-399 > URL: https://issues.jboss.org/browse/CDI-399 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:39:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:39:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a full mvn project and clean dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-421: ------------------------------------- Summary: Organize the project as a full mvn project and clean dependencies (was: Organize the project as a Maven project with modules and clean dependencies) > Organize the project as a full mvn project and clean dependencies > ----------------------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:39:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:39:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a Maven project with modules and clean dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-421: ------------------------------------- Summary: Organize the project as a Maven project with modules and clean dependencies (was: Organize the project as a Maven project with modules) > Organize the project as a Maven project with modules and clean dependencies > --------------------------------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 18 12:49:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 18 Feb 2014 12:49:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-399) Make cdi-api an OSGi bundle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-399. -------------------------------------- Resolution: Done PR merge (only the commit with OSGI info, the other part will be included in the CDI-421 ticket) > Make cdi-api an OSGi bundle > --------------------------- > > Key: CDI-399 > URL: https://issues.jboss.org/browse/CDI-399 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Wed Feb 19 10:18:54 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 19 Feb 2014 16:18:54 +0100 Subject: [cdi-dev] Please review PR 200 (regarding doc generation : CDI-413) Message-ID: Hi all, I just made correction to my PR 200 [1]. Please review the code generation. Be also aware that when tho PR will be integrated all sure doc will be moved from ?spec? directory to 'spec/src/main/doc? directory. Antoine [1] https://github.com/cdi-spec/cdi/pull/200 From issues at jboss.org Wed Feb 19 10:51:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 19 Feb 2014 10:51:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-418 started by Antoine Sabot-Durand. > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 11:27:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 19 Feb 2014 11:27:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-418. -------------------------------------- Resolution: Done > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 19 11:27:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 19 Feb 2014 11:27:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-418) 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946059#comment-12946059 ] Antoine Sabot-Durand commented on CDI-418: ------------------------------------------ Revert to 1.1 version > 28 CDI 1.1 new class files bear @Since 1.2-SNAPSHOT instead of @Since 1.1 > ------------------------------------------------------------------------- > > Key: CDI-418 > URL: https://issues.jboss.org/browse/CDI-418 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.2 Proposed > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > It seems that one [commit done 10 months ago|https://github.com/cdi-spec/cdi/commit/0dbe4a7fe7f3ed1a2d4c4b3ab08e641d39277731] change most of the javadoc @Since information on new CDI 1.1 classes. > We should revevert these to 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Wed Feb 19 11:47:37 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 19 Feb 2014 17:47:37 +0100 Subject: [cdi-dev] Please review PR 203 correction CDI-418 Message-ID: <44375733-F4CC-4FA0-B3FF-12B1C4F9FCCF@sabot-durand.net> Hi, Please review this PR [1] asap since the spec cannot be build in its current state. Thanks, Antoine [1] https://github.com/cdi-spec/cdi/pull/203 From issues at jboss.org Thu Feb 20 08:19:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Feb 2014 08:19:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-405 started by Antoine Sabot-Durand. > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Thu Feb 20 10:24:59 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Thu, 20 Feb 2014 16:24:59 +0100 Subject: [cdi-dev] Switched to GIT Pull Request workflow References: <53048777.6050702@redhat.com> Message-ID: <79969ABA-A5E0-4275-BC76-196A5DC00FD4@sabot-durand.net> Hi All, Thanks to Jozef, we now have a new Jira workflow based on Git that fits better to our actual workflow. You can check it here [1]. Antoine [1] http://bit.ly/Meztf8 From issues at jboss.org Thu Feb 20 13:37:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Feb 2014 13:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-405. -------------------------------------- Resolution: Done > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 20 13:37:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 20 Feb 2014 13:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946586#comment-12946586 ] Antoine Sabot-Durand commented on CDI-405: ------------------------------------------ Please check following Pull Request https://github.com/cdi-spec/cdi/pull/204 > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 02:47:47 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 21 Feb 2014 02:47:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-392 started by Mark Struberg. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 02:49:47 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Fri, 21 Feb 2014 02:49:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946709#comment-12946709 ] Mark Struberg commented on CDI-392: ----------------------------------- pull request available: https://github.com/struberg/cdi/pull/1 > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 03:37:47 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Fri, 21 Feb 2014 03:37:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-422) Wrong example for event qualifier types with members In-Reply-To: References: Message-ID: Martin Kouba created CDI-422: -------------------------------- Summary: Wrong example for event qualifier types with members Key: CDI-422 URL: https://issues.jboss.org/browse/CDI-422 Project: CDI Specification Issues Issue Type: Bug Components: Events Reporter: Martin Kouba Priority: Minor The following snippet in "10.2.2 Event qualifier types with members" is wrong: {code} public void login() { final User user = ...; loggedInEvent.fire( new LoggedInEvent(user), new RoleQualifier() { public String value() { return user.getRole(); } ); } {code} {{javax.enterprise.event.Event.fire()}} method does not have qualifiers param. The example should either use {{Event.select(Annotation...)}} along with {{Event.fire()}} or {{BeanManager.fireEvent(Object, Annotation...)}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Fri Feb 21 05:53:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 21 Feb 2014 05:53:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12946778#comment-12946778 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ Good for me. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Fri Feb 21 05:57:09 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 21 Feb 2014 11:57:09 +0100 Subject: [cdi-dev] PR 204 fixing CDI-405 to check Message-ID: Please check PR 204 [1] fixing CDI-405 [2] Antoine [1] https://github.com/cdi-spec/cdi/pull/204 [2] https://issues.jboss.org/browse/CDI-405 From john.d.ament at gmail.com Sat Feb 22 15:51:17 2014 From: john.d.ament at gmail.com (John D. Ament) Date: Sat, 22 Feb 2014 15:51:17 -0500 Subject: [cdi-dev] Scope of what bean archives an extension applies to Message-ID: Hi all, Quick question. This is mostly from playing around with Weld SE 2.1.2, so I'm not sure if my question is going to be Weld SE specific or be generally applied. Looking through the spec, I did not see any obvious indications of this. What is the scope of the application of an Extension class? Suppose I had a JAR file that had META-INF/services/javax.enterprise.inject.spi.Extension with the contents of some extension class. Should the application of that extension class apply to all JARs within the same classpath? If that extension were listed in a WAR file, would it apply to the WAR and all JAR modules? John From issues at jboss.org Sat Feb 22 15:57:47 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 22 Feb 2014 15:57:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-423) Typo in section 11.3.26 In-Reply-To: References: Message-ID: John Ament created CDI-423: ------------------------------ Summary: Typo in section 11.3.26 Key: CDI-423 URL: https://issues.jboss.org/browse/CDI-423 Project: CDI Specification Issues Issue Type: Bug Reporter: John Ament Priority: Minor There is a typo in 11.3.26 http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bm_obtain_extension The method BeanManager.getExtensions() returns the container?s instance of an Extension class Should be: The method `BeanManager.getExtension(Class clazz)` This matches API docs and the verbiage at the end of the spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Sat Feb 22 16:03:47 2014 From: issues at jboss.org (John Ament (JIRA)) Date: Sat, 22 Feb 2014 16:03:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-423) Typo in section 11.3.26 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947078#comment-12947078 ] John Ament commented on CDI-423: -------------------------------- Pull Request: https://github.com/cdi-spec/cdi/pull/205 > Typo in section 11.3.26 > ----------------------- > > Key: CDI-423 > URL: https://issues.jboss.org/browse/CDI-423 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: John Ament > Priority: Minor > > There is a typo in 11.3.26 > http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bm_obtain_extension > The method BeanManager.getExtensions() returns the container?s instance of an Extension class > Should be: The method `BeanManager.getExtension(Class clazz)` > This matches API docs and the verbiage at the end of the spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 04:07:49 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 24 Feb 2014 04:07:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-382: ----------------------------- Summary: Clarify interceptors are not associated with the result of a producer method (was: Clarify interceptors are not associated with the result of a producer method/field) > Clarify interceptors are not associated with the result of a producer method > ---------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 04:11:47 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 24 Feb 2014 04:11:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-382 stopped by Martin Kouba. > Clarify interceptors are not associated with the result of a producer method > ---------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 04:21:48 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 24 Feb 2014 04:21:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947213#comment-12947213 ] Martin Kouba commented on CDI-382: ---------------------------------- PR sent: https://github.com/cdi-spec/cdi/pull/206 (I cannot figure how to use the new workflow for this issue) The final wording is a little bit modified so that all interceptor bindings are covered (those declared at class level, on stereotypes, etc.) > Clarify interceptors are not associated with the result of a producer method > ---------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 04:29:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Feb 2014 04:29:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947217#comment-12947217 ] Antoine Sabot-Durand commented on CDI-382: ------------------------------------------ Thx. Yes the new workflow is only applied on "bug" and "feature request". I'm going to investigate why. > Clarify interceptors are not associated with the result of a producer method > ---------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Mon Feb 24 05:09:55 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 24 Feb 2014 11:09:55 +0100 Subject: [cdi-dev] Scope of what bean archives an extension applies to In-Reply-To: References: Message-ID: <859F918F-94BE-4891-BFE5-D5B31756B00F@sabot-durand.net> Hi John, Yes it doesn?t seem to be explicitly written (I?m still looking) but reading at the beginning of chapter 12, it?s implicit that there?s one container that do one bean discovery and fire on set of events for type discovered. So IMO, it's implicit that extensions are not limited to their current archive and have the same ? visibility ? level than the CDI container : i.e. the current application. This said, it couldn?t hurt to write it explicitly. Antoine Le 22 f?vr. 2014 ? 21:51, John D. Ament a ?crit : > Hi all, > > Quick question. This is mostly from playing around with Weld SE > 2.1.2, so I'm not sure if my question is going to be Weld SE specific > or be generally applied. > > Looking through the spec, I did not see any obvious indications of > this. What is the scope of the application of an Extension class? > Suppose I had a JAR file that had > META-INF/services/javax.enterprise.inject.spi.Extension with the > contents of some extension class. Should the application of that > extension class apply to all JARs within the same classpath? If that > extension were listed in a WAR file, would it apply to the WAR and all > JAR modules? > > John > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev From issues at jboss.org Mon Feb 24 06:03:47 2014 From: issues at jboss.org (Matus Abaffy (JIRA)) Date: Mon, 24 Feb 2014 06:03:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947274#comment-12947274 ] Matus Abaffy commented on CDI-392: ---------------------------------- Maybe a magic formula "non-portable behavior results" would be more consistent with the spec. than "in order to prevent random behaviour" as it is used throughout the whole text. WDYT? Otherwise good for me as well. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 06:07:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Feb 2014 06:07:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-382. -------------------------------------- Resolution: Done PR 206 integrated > Clarify interceptors are not associated with the result of a producer method > ---------------------------------------------------------------------------- > > Key: CDI-382 > URL: https://issues.jboss.org/browse/CDI-382 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.1.PFD > Reporter: Martin Kouba > Assignee: Martin Kouba > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec. > [1] https://github.com/cdi-spec/cdi/pull/110 > "Interceptors are not associated with the return value of a producer method or the current value of a producer field." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 06:23:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Feb 2014 06:23:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947286#comment-12947286 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ [~bafco] In fact, the wording used by [~struberg] is a shortcut to mix the fact that either the container will throw an exception either it will provide non portable behavior depending on the impl... > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Mon Feb 24 10:47:17 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 24 Feb 2014 16:47:17 +0100 Subject: [cdi-dev] Spec document moved in the repo Message-ID: Hi All, Just to inform you that I just merged PR 200, so spec files moved from ?spec' to 'spec/src/main/doc?. Thanks to git it shouldn?t impact your work in progress on spec doc. Antoine From issues at jboss.org Mon Feb 24 11:21:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Feb 2014 11:21:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reopened CDI-405: -------------------------------------- > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 11:21:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 24 Feb 2014 11:21:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-405 started by Antoine Sabot-Durand. > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Mon Feb 24 12:39:48 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 24 Feb 2014 12:39:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947516#comment-12947516 ] Mark Struberg commented on CDI-377: ----------------------------------- +1 for option 2. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 02:21:47 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 25 Feb 2014 02:21:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947729#comment-12947729 ] Jozef Hartinger commented on CDI-392: ------------------------------------- If you know upfront that the container throws an exception, how is that random? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 02:59:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 02:59:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947738#comment-12947738 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ [~jharting] I'm not happy with this fuzzy behavior but the java doc states : {quote} *Throws :* IllegalStateException - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getReference(Bean, Type, CreationalContext) may be called from an observer of the AfterBeanDiscovery event. {quote} > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 03:39:48 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 25 Feb 2014 03:39:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947758#comment-12947758 ] Jozef Hartinger commented on CDI-392: ------------------------------------- My point is that *random* is not an appropriate adjective to use here, as the behavior is pretty predictable. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 05:23:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 05:23:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947802#comment-12947802 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ Thanks for the input [~jharting]. What do you think of this wording guys ? {quote} Most operations of BeanManager may be called at any time during the execution of the application. However calling some BeanManager operations before the AfterDeploymentValidation event is fired will cause the container to throw an IllegalStateException (The container is permitted to define a non-portable mode in which these operation may be called from an observer of the AfterBeanDiscovery event) {quote} > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 10:17:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 10:17:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12947937#comment-12947937 ] Antoine Sabot-Durand commented on CDI-280: ------------------------------------------ After having checked the majority of the 1904 Bean occurrences in the spec and to provide a consistent approach I propose these names * The class that gets Scanned : *Bean Class* (_quite obvious_) * The Bean : *Bean Metadata* (_because the previous defined *Bean Class* is not {{Bean.class}}_) * The instance : *Bean* or *Bean Instance* (_The most accepted usage in the spec and in other IoC framework_) * The proxy on the instance : *Bean client proxy* or *Client proxy* (_Already in the spec even if I don't like the term "proxy"_) * Type of injection type : *InjectionPoint Type* (_obvious_) * EJB Bean : *Session Bean* (_obvious_) The idea is to start from the user point of view. The _Bean_ is the object instance that gets injected in the developer code. It has the required _Bean Class_ and the container stores its _Bean Metadata_. Some _Bean_ are not injected directly but are wrapped in _Client Proxy_ to provide CDI services. _Bean_ are provided by the container which use _Injection Point Type_ and Qualifiers to retrieve the corresponding _Bean Metadata_ to lookup for or create the _Bean_ which can be wrapped in a _Client Proxy_ if needed. I also propose that these terms should be introduced at the beginng of the spec. > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 10:31:49 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 10:31:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-377: ---------------------------------------- Assignee: Antoine Sabot-Durand > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 10:35:51 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 10:35:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-377 started by Antoine Sabot-Durand. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 12:55:49 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 12:55:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948028#comment-12948028 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ PR sent https://github.com/cdi-spec/cdi/pull/208 > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Tue Feb 25 12:57:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 25 Feb 2014 12:57:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-377: ------------------------------------- Git Pull Request: https://github.com/cdi-spec/cdi/pull/208 > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Tue Feb 25 13:02:42 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 25 Feb 2014 19:02:42 +0100 Subject: [cdi-dev] Please review Proposal for CDI-377 Message-ID: Hi all, As stated yesterday. I made a proposal regarding CDI-377 resolution. It?s in https://github.com/cdi-spec/cdi/pull/208 As it is an important bug, I suggest that all of you take time to read these few line and make their feedback so I can rework it. Anyway, This modification won?t be included before Pete returns and gives his validation (or not) as he asked. Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140225/3b47b330/attachment.bin From issues at jboss.org Wed Feb 26 03:17:47 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 26 Feb 2014 03:17:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948186#comment-12948186 ] Jozef Hartinger commented on CDI-392: ------------------------------------- That looks better. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 04:03:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 04:03:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948199#comment-12948199 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ Even if it looks like a common statement after negotiations between 2 political party ;-) What do you think [~struberg] ? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:05:49 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 26 Feb 2014 05:05:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948228#comment-12948228 ] Mark Struberg commented on CDI-392: ----------------------------------- Well, there is nothing in the API which says that this is optional for the BeanManager. We usually use the wording 'non-portable behaviour results' for parts which does exactly that. But in the case of calling getBeans during the build-up of the Beans itself it's not non-portable but it's really just broken due to the randomness of the bean-discovery order. This has nothing to do with non-portable but really is broken. This is hardly detectable by junior developers as it is similar to concurrency issues in such that it appears randomly. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:09:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:09:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948230#comment-12948230 ] Antoine Sabot-Durand commented on CDI-280: ------------------------------------------ While we implicitly included CDI-406 in this ticket we missed CDI-404. We should analyse the impact of adding {{@Interceptor}} and {{@Decorator}} in the list of bean defining annotations. > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:19:49 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:19:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948238#comment-12948238 ] Antoine Sabot-Durand commented on CDI-377: ------------------------------------------ Now that we chose to work on the list of defining bean annotations to solve this ticket we should take in consideration other tickets questioning the content of this list. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:19:51 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:19:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948238#comment-12948238 ] Antoine Sabot-Durand edited comment on CDI-377 at 2/26/14 5:19 AM: ------------------------------------------------------------------- Now that we chose to work on the list of defining bean annotations to solve this ticket we should take in consideration other tickets questioning the content of this list. That would be CDI-404, CDI-406 and CDI-408. was (Author: antoinesabot-durand): Now that we chose to work on the list of defining bean annotations to solve this ticket we should take in consideration other tickets questioning the content of this list. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:19:52 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:19:52 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-406) Make stereotypes bean defining annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-406: ---------------------------------------- Assignee: Antoine Sabot-Durand > Make stereotypes bean defining annotations > ------------------------------------------ > > Key: CDI-406 > URL: https://issues.jboss.org/browse/CDI-406 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > For example @Model -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:21:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:21:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-404: ---------------------------------------- Assignee: Antoine Sabot-Durand > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:21:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:21:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-408: ---------------------------------------- Assignee: Antoine Sabot-Durand > bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans > --------------------------------------------------------------------------- > > Key: CDI-408 > URL: https://issues.jboss.org/browse/CDI-408 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Reporter: Jens Schumann > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly. > However there are two impacts: > 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere. > 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere. > I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier. > If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD. > -- > [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;) > > Btw: Which JIRA version is CDI 1.1 Final? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:43:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 05:43:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948247#comment-12948247 ] Antoine Sabot-Durand commented on CDI-392: ------------------------------------------ {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of `getBeans(Type beanType, Annotation... qualifiers)` at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 05:55:49 2014 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 26 Feb 2014 05:55:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948253#comment-12948253 ] Mark Struberg commented on CDI-392: ----------------------------------- Ah oki, well didn't see that this is optional. In that case the non-portable wording is fine. I also agree about thinking whether we remove this non-portable thingy. It's really just broken. > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine.sabotdurand at gmail.com Wed Feb 26 08:08:57 2014 From: antoine.sabotdurand at gmail.com (antoine.sabotdurand at gmail.com) Date: Wed, 26 Feb 2014 13:08:57 +0000 Subject: [cdi-dev] Updated Invitation: CDI 1.2 MR meeting @ Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 (Perso) Message-ID: <001a11c33eb24b838304f34ee884@google.com> This event has been changed. Title: CDI 1.2 MR meeting Proposed agenda : - Ready to fix review and assignation - Discussion on other ticket - Progess and obstacles View your event at http://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en. When: Weekly from 6pm to 7pm on Monday from Mon Jan 27 to Mon Mar 31 Paris (changed) Where: IRC #jsr346 Channel on Freenode Calendar: Perso Who: (Guest list has been hidden at organizer's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=XzhjbzQyZGE2ODUzNDJiOWg4a28zYWI5azZncmsyYmEyOGNxa2NiYTY2bDEzOGQyMzY0c2pnZHEyNmsgY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjkjYW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb200ODZmMTU2NTBmYjQzNmY5ZmEzZTUxMGNmODczNDA2MDIyMDViNzM4&ctz=Europe/Paris&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account cdi-dev at lists.jboss.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20140226/78dbebf5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1949 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140226/78dbebf5/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2005 bytes Desc: not available Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140226/78dbebf5/attachment-0001.bin From issues at jboss.org Wed Feb 26 08:08:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 08:08:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948247#comment-12948247 ] Antoine Sabot-Durand edited comment on CDI-392 at 2/26/14 8:06 AM: ------------------------------------------------------------------- {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of {{getBeans(Type beanType, Annotation... qualifiers)}} at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? was (Author: antoinesabot-durand): {quote} Well, there is nothing in the API which says that this is optional for the BeanManager. {quote} If I look at the javadoc of `getBeans(Type beanType, Annotation... qualifiers)` at the end I read {quote} *Throws :* *IllegalStateException* - if called during application initialization, before the AfterDeploymentValidation event is fired The container is permitted to define a non-portable mode in which getBeans(Type, Annotation...) may be called from an observer of the AfterBeanDiscovery event. {quote} My understanding was that it's not allowed but that an implementation is allowed to define a non-portable behavior by allowing the call after AfterBeanDiscovery event is fired. >From what you say [~struberg], I understand that I misunderstood that point. So why don't we forbid definitively call to these operations before AfterDeploymentValidation event to avoid junior developers to create futur bugs ? > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Assignee: Mark Struberg > Labels: CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:16:51 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:16:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948374#comment-12948374 ] Antoine Sabot-Durand commented on CDI-404: ------------------------------------------ As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:16:51 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:16:51 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948374#comment-12948374 ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:15 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:16:52 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:16:52 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948374#comment-12948374 ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:16 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid compatibility issues with existing JSR-330 implementing framework (issue describe in CDI-377). I checked that the 3 big framework implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:18:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:18:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948374#comment-12948374 ] Antoine Sabot-Durand edited comment on CDI-404 at 2/26/14 9:17 AM: ------------------------------------------------------------------- As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. was (Author: antoinesabot-durand): As CDI-377 is now focused on redefining list of bean defining annotations, I added it as a dependency of this ticket. To avoid a new CDI-377, I checked that the 3 big frameworks implementing JSR-330 : * Guice (and Maven3 new extension mechanism), * Spring, * Dagger, to be sure they don't implement Interceptor Spec as well. So I can tell they don't use {{@Interceptor}} annotation so it is safe to add it to the list of bean defining annotations. There is no such problem regarding {{@Decorator}} since it's part of CDI spec. I'll change PR 208 to include this ticket. > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:20:48 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:20:48 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-404: ------------------------------------- Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge CDI_tck_chge) > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-java-ee7 > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:22:50 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:22:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-377: ------------------------------------- Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge CDI_tck_chge) > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 09:44:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 09:44:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948383#comment-12948383 ] Antoine Sabot-Durand commented on CDI-408: ------------------------------------------ IMHO we have 3 solution to address this issue ( # Add to the bean defining annotation list {{@Produces}} and {{@Observes}}. That will add to the list annotations *inside* a class. # Detect {{@Produces}} and {{@Observes}} in class that don't have bean defining annotation and warn the user at boot time. It seems to be a work very close to previous point in term of scanning. # Do nothing in the container and only document in spec the fact that in {{annotated}} mode these will be ignored silently. Not very user friendly but {{bean-discovery-mode=all}} is not out of reach ;). Ideally I would prefer the first solution but do we have time to implement this for the MR? Input from implementors ([~jharting], [~struberg] or [~mkouba]) seems mandatory here. > bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans > --------------------------------------------------------------------------- > > Key: CDI-408 > URL: https://issues.jboss.org/browse/CDI-408 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Reporter: Jens Schumann > Assignee: Antoine Sabot-Durand > Labels: CDI_spec_chge > Fix For: 1.2 Proposed > > > Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly. > However there are two impacts: > 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere. > 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere. > I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier. > If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD. > -- > [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;) > > Btw: Which JIRA version is CDI 1.1 Final? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 10:30:50 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 10:30:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-280: ------------------------------------- Comment: was deleted (was: While we implicitly included CDI-406 in this ticket we missed CDI-404. We should analyse the impact of adding {{@Interceptor}} and {{@Decorator}} in the list of bean defining annotations.) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 10:30:50 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 10:30:50 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-280: ------------------------------------- Labels: CDI_api_chge CDI_spec_chge Ready_to_fix (was: CDI_spec_chge) > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From antoine at sabot-durand.net Wed Feb 26 10:42:21 2014 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 26 Feb 2014 16:42:21 +0100 Subject: [cdi-dev] Please review proposed names in CDI-280 Message-ID: Hi Al, CDI-280 - clarify usage of 'bean' term usage in the spec [1] is one of the longest ticket to treat as it involves re-reading all the spec and check the name fro all ? bean ? occurrences in the text. I counted 1904 occurrences in the spec, didn?t check the Javadoc but there should be a bunch too here. All this to say that this ticket should be started very soon. I made a final proposal for the name and put the ticket in Ready_to_fix mode. That means that if you have concern with my proposed names you should raise your hand before friday 4:00pm GMT. Thanks for your input including conter proposal if you don?t like mine. Antoine [1] https://issues.jboss.org/browse/CDI-280 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20140226/1dfaf812/attachment.bin From issues at jboss.org Wed Feb 26 11:40:49 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 26 Feb 2014 11:40:49 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948444#comment-12948444 ] Martin Kouba commented on CDI-280: ---------------------------------- I don't think this clarification will help to understand "5.5.8 Bean metadata" better (this section is just complicated). I wouldn't introduce *Bean Metadata* but rather continue with *Bean*. *Bean Metadata* might be more correct but also possible source of confusion. We should definitely check whether we use *Bean instance* (aka contextual instance of a *Bean*) consistently. *Bean Class* - OK *Proxy* - I'm not sure, to my understanding _client proxy_ and _contextual reference_ are synonyms with some formal differences *InjectionPoint Type* - NOK, the spec uses _required type_ consistently (see 5.2 Typesafe resolution), also I don't see any confusion here *Session bean* - OK > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Wed Feb 26 15:42:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 26 Feb 2014 15:42:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948498#comment-12948498 ] Antoine Sabot-Durand commented on CDI-280: ------------------------------------------ {quote} I don't think this clarification will help to understand "5.5.8 Bean metadata" better (this section is just complicated). {quote} Yes, I agree: more example sooner in this chapter would benefit understanding. {quote} I wouldn't introduce Bean Metadata but rather continue with Bean. Bean Metadata might be more correct but also possible source of confusion. {quote} In fact Bean Metadata is already introduced : 5.5.8 use this term many times. And I really think we should have distinctive name between the bean instance and the bean metadata, it's the purpose of this ticket. {quote} We should definitely check whether we use Bean instance (aka contextual instance of a Bean) consistently. {quote} In theory it's the best term, but everybody use the *Bean* abbreviation. So, IMO, we really should reserved the term *Bean* to shorten the *Bean Instance* and for nothing else. That said I agree we should try to use *Bean Instance* in the spec. {quote} Proxy - I'm not sure, to my understanding client proxy and contextual reference are synonyms with some formal differences {quote} Yes they're synonyms. I prefer *Bean Reference* but there are so much occurrence of *Proxy* or *Client proxy* in the spec that I hesitate to switch to *Bean Reference*. {quote} InjectionPoint Type - NOK, the spec uses required type consistently (see 5.2 Typesafe resolution), also I don't see any confusion here {quote} Agree > clarify usage of 'bean' term usage in the spec > ---------------------------------------------- > > Key: CDI-280 > URL: https://issues.jboss.org/browse/CDI-280 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mark Struberg > Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix > Fix For: 1.2 Proposed > > > We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for > * The Bean extends Contextual. Should be referred as 'Bean' or 'CDI Bean' > * The class which gets scanned. Should be referred as 'Bean Class' to > * The instance stored in the context. Should be referred to as 'Contextual Instance' > * The proxy for a Contextual Instance should be referred to as 'Contextual Reference' > * The type of an injection point should be referred to as 'InjectionPoint Type' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From issues at jboss.org Thu Feb 27 04:20:47 2014 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 27 Feb 2014 04:20:47 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-421) Organize the project as a full mvn project and clean dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CDI-421 started by Antoine Sabot-Durand. > Organize the project as a full mvn project and clean dependencies > ----------------------------------------------------------------- > > Key: CDI-421 > URL: https://issues.jboss.org/browse/CDI-421 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Labels: Ready_to_fix > Fix For: 1.2 Proposed > > > Right now only the api sub-directory is a maven project. The spec part of the CDI spec project is managed with script. > With CDI-413, we'll introduce Maven as the doc generation tool, so to ease the project management we should organize all as a maven project with a doc module and a api module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira From debian at good-with-numbers.com Tue Feb 18 00:07:33 2014 From: debian at good-with-numbers.com (Mike) Date: Tue, 18 Feb 2014 05:07:33 -0000 Subject: [cdi-dev] typo in section 12.1 of JSR 346 Final Message-ID: <20140218050732.GA13632@64-142-29-25.dsl.static.sonic.net> http://download.oracle.com/otn-pub/jcp/cdi-1_1-fr-eval-spec/cdi-spec.pdf Find "bean-discovey-mode".