From issues at jboss.org Thu Jun 1 03:22:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 1 Jun 2017 03:22:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414719#comment-13414719 ] Matej Novotny commented on CDI-703: ----------------------------------- [~struberg] but that's the whole point of [transitive relation|https://en.wikipedia.org/wiki/Transitive_relation]. Indirect specialization is defined through transitive relation, in gibberish that is ? a , b , c ? X : ( a R b ? b R c ) ? a R c And the very next part of spec follows up on this and mentions the qualifiers: bq. Then X will inherit the qualifiers and bean name of Y: ... The word *then* referes to 'when X specializes Y' from the previous paragraph. So let's have a following chain of beans: {code} @QualifierA class A{...} @QualifierB @Specializes class B extends A{...} @QualifierC @Specializes class C extends B{...} {code} Now all that is needed is to substitute {{X}} and {{Y}} (from spec statements) for beans and explore how the transitive relation affects this. There are two statements: a) Formally, a bean X is said to specialize another bean Y if there is either: -> true if specialization exists b) Then X will inherit the qualifiers and bean name of Y: -> true if a) is true Now let's apply this to the above shown beans: * Bean A ** Nothing interesting, the basic bean which will be replaced * Bean B ** Direct specialization of A *** X=B, Y=A *** a) true, specialization exists *** b) true, qualifier {{@QualifierA}} is inherited * Bean C ** Direct specialization of B (also defined in spec in [chapter 3.1.4|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#specialize_managed_bean] *** X=C, Y=B *** a) true, specialization exists *** b) true, qualifier {{@QualifierB}} is inherited ** Indirect specialization of A *** Implied by transitive relation, if C specializes B and B specializes A, then C specializes A *** Therefore X=C, Y=A *** a) true, indirect specialization exists *** b) since a) is valid, this hold true *and C has to inherit qualifier {{@QualifierA}}* from A > Carify indirect specialization > ------------------------------ > > Key: CDI-703 > URL: https://issues.jboss.org/browse/CDI-703 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean. > Discussion in CDITCK-580 illustrates this concern. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 1 04:07:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 1 Jun 2017 04:07:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414736#comment-13414736 ] Mark Struberg commented on CDI-703: ----------------------------------- But if your assumption would be correct, then you need to apply the same rules to @Named, right? Which is quite deadly... > Carify indirect specialization > ------------------------------ > > Key: CDI-703 > URL: https://issues.jboss.org/browse/CDI-703 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean. > Discussion in CDITCK-580 illustrates this concern. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 1 04:28:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 1 Jun 2017 04:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414760#comment-13414760 ] Matej Novotny commented on CDI-703: ----------------------------------- It's not my assumption, that's how transitive relation works by definition. As for {{@Named}} this is clear too, just look few lines below that, where the spec says: bq. If Y has a bean name and X declares a bean name explicitly the container automatically detects the problem and treats it as a definition error. Again, apply transitive relation rules and you have a result -> definition error if both have {{@Named}}. > Carify indirect specialization > ------------------------------ > > Key: CDI-703 > URL: https://issues.jboss.org/browse/CDI-703 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean. > Discussion in CDITCK-580 illustrates this concern. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 1 04:29:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 1 Jun 2017 04:29:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-703) Carify indirect specialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414760#comment-13414760 ] Matej Novotny edited comment on CDI-703 at 6/1/17 4:28 AM: ----------------------------------------------------------- It's not my assumption, that's how transitive relation works by definition. As for {{@Named}} this is clear too, just look few lines below that, where the spec says: bq. If Y has a bean name and X declares a bean name explicitly the container automatically detects the problem and treats it as a definition error. Again, apply substitution and you have a result -> definition error if both have {{@Named}}. was (Author: manovotn): It's not my assumption, that's how transitive relation works by definition. As for {{@Named}} this is clear too, just look few lines below that, where the spec says: bq. If Y has a bean name and X declares a bean name explicitly the container automatically detects the problem and treats it as a definition error. Again, apply transitive relation rules and you have a result -> definition error if both have {{@Named}}. > Carify indirect specialization > ------------------------------ > > Key: CDI-703 > URL: https://issues.jboss.org/browse/CDI-703 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 2.0 .Final > Reporter: Antoine Sabot-Durand > > Indirect specialization in chapter 4.3.1 lacks clarification regarding intermediate beans attributes (qualifier and name) on specializing bean bean. > Discussion in CDITCK-580 illustrates this concern. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From ljnelson at gmail.com Thu Jun 1 13:09:28 2017 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 01 Jun 2017 17:09:28 +0000 Subject: [cdi-dev] JSR 250 version? Message-ID: I'm sure I missed something somewhere, but what version of JSR 250 (Common Annotations for the Java? Platform?) does CDI 2.0 require? I *assume* it's 1.3, but I didn't see any reference to this annotations specification in the CDI specification. Thanks, Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170601/715d757e/attachment-0001.html From tremes at redhat.com Fri Jun 2 01:57:44 2017 From: tremes at redhat.com (Tomas Remes) Date: Fri, 2 Jun 2017 01:57:44 -0400 (EDT) Subject: [cdi-dev] JSR 250 version? In-Reply-To: References: Message-ID: <1831323297.4280941.1496383064195.JavaMail.zimbra@redhat.com> Hi Laird, I think CDI API doesn't require this dependency, but Weld 3 needs JSR 250 dependency with 1.3 version. Tom ----- Original Message ----- From: "Laird Nelson" To: "cdi-dev" Sent: Thursday, June 1, 2017 7:09:28 PM Subject: [cdi-dev] JSR 250 version? I'm sure I missed something somewhere, but what version of JSR 250 (Common Annotations for the Java? Platform?) does CDI 2.0 require? I assume it's 1.3, but I didn't see any reference to this annotations specification in the CDI specification. Thanks, Best, Laird _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From struberg at yahoo.de Fri Jun 2 04:50:09 2017 From: struberg at yahoo.de (Mark Struberg) Date: Fri, 2 Jun 2017 10:50:09 +0200 Subject: [cdi-dev] JSR 250 version? In-Reply-To: <1831323297.4280941.1496383064195.JavaMail.zimbra@redhat.com> References: <1831323297.4280941.1496383064195.JavaMail.zimbra@redhat.com> Message-ID: <9D9ABF11-0B33-4B6A-9DC5-7E377B869599@yahoo.de> Well, it's true that the API does not have any dependency on common-annotations. But strictly speaking the CDI 2.0 Specification _does_ require common-annotations-1.3 for @Priority on @Observes parameters. Should we have pointed this out in the spec pdf? We might add it as errata... LieGrue, strub > Am 02.06.2017 um 07:57 schrieb Tomas Remes : > > > Hi Laird, > > I think CDI API doesn't require this dependency, but Weld 3 needs JSR 250 dependency with 1.3 version. > > Tom > > ----- Original Message ----- > From: "Laird Nelson" > To: "cdi-dev" > Sent: Thursday, June 1, 2017 7:09:28 PM > Subject: [cdi-dev] JSR 250 version? > > I'm sure I missed something somewhere, but what version of JSR 250 (Common Annotations for the Java? Platform?) does CDI 2.0 require? I assume it's 1.3, but I didn't see any reference to this annotations specification in the CDI specification. > > Thanks, > Best, > Laird > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. From issues at jboss.org Mon Jun 5 09:02:01 2017 From: issues at jboss.org (=?UTF-8?Q?Guillermo_Gonz=C3=A1lez_de_Ag=C3=BCero_=28JIRA=29?=) Date: Mon, 5 Jun 2017 09:02:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-701) Should addSterotype trigger discovery of new annotated types? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416270#comment-13416270 ] Guillermo Gonz?lez de Ag?ero commented on CDI-701: -------------------------------------------------- FYI, the JAX-RS expert group is now discussing ways to improve CDI integration and I think this issue or something like it could help there: https://javaee.groups.io/g/jaxrs-spec/topic/cdi_integration/5113885?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5113885 > Should addSterotype trigger discovery of new annotated types? > ------------------------------------------------------------- > > Key: CDI-701 > URL: https://issues.jboss.org/browse/CDI-701 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Guillermo Gonz?lez de Ag?ero > Fix For: 2.1 (Discussion) > > > I've tried to post this question to the mailing list multiple times without success, so I fill an issue for it. > I'm adding some annotations as stereotypes via an extension, with the purpose of converting into beans any classes annotated with them (JAX-RS resources in my specific case). What I'm facing is that classes with that annotations are still only discovered if they were to be discovered before. So when using discovery-mode="annotated", my JAX-RS resources are not passed to the @ProcessAnnotatedType event. > WildFly automatically converts JAX-RS resources into @RequestScoped CDI beans, but looking at the code I saw it does that dealing directly with Weld APIs at server level, not on a portable manner at RESTEasy level. > I haven't found any mention in the spec that my approach wouldn't work, but the TCK doesn't address this usecase, which makes me think it's not supported. > Could you please clarify me the situation? Could this me changed on a future version? > And the original email I sent: > {quote} > Hi, > > I have a question about the behavior of the "BeforeBeanDiscovery#add*()" methods. > > My usecase is the following: I'd want to convert all JAX-RS resources into CDI beans. That resources are all annotated with @Path. My understanding was that converting that annotation into a stereotype would make them eligible as bean types. > > Since I can't modify that annotation, I just created an extension that observes the BeforeBeanDiscovery event and converts @Path into a stereotype associated with the @RequestScoped annotation. But it doesn't work, neither on Weld nor on OpenWebBeans. The class is not discovered on the next ProcessAnnotatedType event. > > I haven't found anything in the spec that explicitly says that a "runtime added" bean defining annotation makes clases eligible for discovery. But I think is makes sense. > > Checking the TCK, test org.jboss.cdi.tck.tests.extensions.stereotype.StereotypeExtensionTest tests that the addition of the stereotype works, but doesn't cover my case of adding a stereotype to a non bean class. > > Is this expected to work that way? Is a bug on the TCK and implementations? Any other way to achieve my goal? > > > Regards, > Guillermo Gonz?lez de Ag?ero > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 03:56:01 2017 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 6 Jun 2017 03:56:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: Tomas Remes created CDI-705: ------------------------------- Summary: BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback Key: CDI-705 URL: https://issues.jboss.org/browse/CDI-705 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 2.0 .Final Reporter: Tomas Remes In {{10.4.5. Transactional observer methods}} CDI spec states: {quote} If the transaction is in progress, but javax.transaction.Synchronization callback cannot be registered due to the transaction being already marked for rollback or in state where javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. {quote} This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: {quote} The Synchronization.beforeCompletion method is called prior to the start of the two-phase transaction commit process. This call is executed with the transaction context of the transaction that is being committed. {quote} So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 07:13:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Jun 2017 07:13:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416821#comment-13416821 ] Tom Jenkinson commented on CDI-705: ----------------------------------- Maybe [~antoinesabot-durand] have a reason why the specifications differentiate? I can see the handling was added in WELD-2120 (PRs were merged even though Jira shows them as declined). There was a textual change to the spec too: https://github.com/cdi-spec/cdi/pull/370/files (thanks for the reference [~ochaloup]) > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 07:19:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Jun 2017 07:19:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416829#comment-13416829 ] Martin Kouba commented on CDI-705: ---------------------------------- It was probably just an oversight. To be honest I always thought that {{javax.transaction.Synchronization.beforeCompletion()}} is also called for a tx that was rolled back because the "two-phase transaction commit process" also handles "failure commit phase". [~tomjenkinson] From the tx point of view what is the reason not to call this method? > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 07:45:03 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Jun 2017 07:45:03 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416864#comment-13416864 ] Tom Jenkinson commented on CDI-705: ----------------------------------- IMO it is that way for JTA because there is no need to call BC/AC in abort case, if you look at JPA and similar they will likely do their flushes during BC. Feel free to follow up on the TX side of things in our community: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d or there is the JTA spec community also: https://javaee.groups.io/g/jta-spec/topics > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 08:11:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Jun 2017 08:11:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416880#comment-13416880 ] Martin Kouba commented on CDI-705: ---------------------------------- Well, {{Synchronization.afterCompletion()}} should be called even if a tx is rolled back. But it probably makes sense to skip BC. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 08:45:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Jun 2017 08:45:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416917#comment-13416917 ] Tom Jenkinson commented on CDI-705: ----------------------------------- AC is already defined as called an undefined transaction context so I wonder what it is that you want to do in AC when abort is called? But again, perhaps best to discuss on the forum. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 08:47:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Jun 2017 08:47:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416918#comment-13416918 ] Martin Kouba commented on CDI-705: ---------------------------------- [~tomjenkinson] Well, I don't want to do anything ;-) I'm just curious. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 09:20:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 6 Jun 2017 09:20:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416960#comment-13416960 ] Ondra Chaloupka commented on CDI-705: ------------------------------------- Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction is going to be committed. When the transaction is not going to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous) and at that time the transaction context could not be available. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 09:21:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 6 Jun 2017 09:21:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416960#comment-13416960 ] Ondra Chaloupka edited comment on CDI-705 at 6/6/17 9:20 AM: ------------------------------------------------------------- Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction *is going* to be committed. When the transaction *is not going* to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous) and at that time the transaction context could not be available. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. was (Author: ochaloup): Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction is going to be committed. When the transaction is not going to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous) and at that time the transaction context could not be available. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 09:22:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 6 Jun 2017 09:22:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416960#comment-13416960 ] Ondra Chaloupka edited comment on CDI-705 at 6/6/17 9:21 AM: ------------------------------------------------------------- Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction *is going* to be committed. When the transaction *is not going* to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous). Plus at that time the transaction context could not be available (as txn could be rolled back) and operations working on beforeCompletion context is expecting to use it. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. was (Author: ochaloup): Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction *is going* to be committed. When the transaction *is not going* to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous) and at that time the transaction context could not be available. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 09:23:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 6 Jun 2017 09:23:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416960#comment-13416960 ] Ondra Chaloupka edited comment on CDI-705 at 6/6/17 9:22 AM: ------------------------------------------------------------- Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction *is going* to be committed. When the transaction *is not going* to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous). Plus at that time the transaction context could not be available (as txn could be rolled back) and operations working on beforeCompletion context is expecting to use it. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there isn't any notion of it. From that point, both cases are the same. was (Author: ochaloup): Tom already mentioned it so these are just my two cents: as I understand it, the main difference is in the fact that {{beforeCompletion}} is expected to be called with the active transaction context (by spec it's required). That provides the way for e.g. JPA (as Tom mentioned) to call flushes etc. That's are operations which are needed for data changes being made visible for the consumer - that's when the transaction *is going* to be committed. When the transaction *is not going* to be committed (was rolled back or marked to roll back) then first there is no need for such operations (and they could be considered as superfluous). Plus at that time the transaction context could not be available (as txn could be rolled back) and operations working on beforeCompletion context is expecting to use it. The {{afterCompletion}} is expected to be called without active transaction context - that's true for commit and rollback. For both cases, the transaction already finished and there could not be any notion of it. Those cases are the same in that way. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 09:24:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 6 Jun 2017 09:24:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416971#comment-13416971 ] Martin Kouba commented on CDI-705: ---------------------------------- [~ochaloup] Thanks for your explanation. That makes sense. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 08:09:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Jun 2017 08:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417641#comment-13417641 ] Antoine Sabot-Durand commented on CDI-705: ------------------------------------------ Obviously, we introduced a mistake in CDI 2.0 by mentioning that transactional observers bound to {{BEFORE_COMPLETION}} phase should be called even if the transaction is rolled back or marked as rolled back. I plan to contact the EG to propose that we ignore this feature and align on JTA behaviour (related [test|https://github.com/antoinesd/cdi-tck/blob/2092263827d68253e2a74c6150c387e829f0382f/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java] in TCK should also be ignored and this ticket will have to be corrected in a coming CDI 2.0 MR IMO. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 08:21:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Jun 2017 08:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417641#comment-13417641 ] Antoine Sabot-Durand edited comment on CDI-705 at 6/7/17 8:20 AM: ------------------------------------------------------------------ Obviously, we introduced a mistake in CDI 2.0 by mentioning that transactional observers bound to {{BEFORE_COMPLETION}} phase should be called even if the transaction is rolled back or marked as rolled back. I plan to contact the EG to propose that we ignore this feature and align on JTA behaviour (related [test|https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java] in TCK should also be ignored and this ticket will have to be corrected in a coming CDI 2.0 MR IMO. was (Author: antoinesabot-durand): Obviously, we introduced a mistake in CDI 2.0 by mentioning that transactional observers bound to {{BEFORE_COMPLETION}} phase should be called even if the transaction is rolled back or marked as rolled back. I plan to contact the EG to propose that we ignore this feature and align on JTA behaviour (related [test|https://github.com/antoinesd/cdi-tck/blob/2092263827d68253e2a74c6150c387e829f0382f/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java] in TCK should also be ignored and this ticket will have to be corrected in a coming CDI 2.0 MR IMO. > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 08:23:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Wed, 7 Jun 2017 08:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-705) BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-705: ------------------------------------- Fix Version/s: 2.0.1 > BEFORE_COMPLETION Transactional observer is notified for transaction which is marked for rollback > ------------------------------------------------------------------------------------------------- > > Key: CDI-705 > URL: https://issues.jboss.org/browse/CDI-705 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0 .Final > Reporter: Tomas Remes > Fix For: 2.0.1 > > > In {{10.4.5. Transactional observer methods}} CDI spec states: > {quote} > If the transaction is in progress, but javax.transaction.Synchronization callback cannot be > registered due to the transaction being already marked for rollback or in state where > javax.transaction.Synchronization callbacks cannot be registered, the before completion, after completion and after failure observer methods are notified at the same time as other observers, but after_success observer methods get skipped. > {quote} > This doesn't conform to JTA spec, which says in {{3.3.2 Transaction Synchronization}}: > {quote} > The Synchronization.beforeCompletion method is called prior to the > start of the two-phase transaction commit process. This call is executed with > the transaction context of the transaction that is being committed. > {quote} > So the before_completion transactional observer shouldn't be notified for transaction marked for rollback. > The method {{Synchronization.beforeCompletion}} is actually not called at WildFly and GlassFish app servers for transaction which is marked for rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From asabotdu at redhat.com Wed Jun 7 08:21:05 2017 From: asabotdu at redhat.com (Antoine Sabot-Durand) Date: Wed, 7 Jun 2017 14:21:05 +0200 Subject: [cdi-dev] Proposal regarding CDI-705 Message-ID: Hi all, It seems that we introduced a mistake in CDI 2.0 regarding its alignment with JTA. See?https://issues.jboss.org/browse/CDI-705 Transactional observer bound to?BEFORE_COMPLETION shouldn?t be triggered if the transaction is rolled back or marked for roll back. I suggest that we skip the matching test in the TCK [1] and allow impl to skip this rule and align on JTA. JTA should be corrected in a coming MR. Thanks for your feedback Antoine [1]?https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170607/2c8fee12/attachment.html From antoine at sabot-durand.net Wed Jun 7 15:57:46 2017 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 7 Jun 2017 21:57:46 +0200 Subject: [cdi-dev] Proposal for CDI-705 Message-ID: Hi all, It seems that we introduced a mistake in CDI 2.0 regarding its alignment with JTA. See?issues.jboss.org/browse/CDI-705 Transactional observer bound to?BEFORE_COMPLETION shouldn?t be triggered if the transaction is rolled back or marked for roll back. I suggest that we skip the matching test in the TCK [1] and allow impl to skip this rule and align on JTA. JTA should be corrected in a coming MR. Thanks for your feedback [1]?github.com/cdi-s...t.java Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170607/74c89c2e/attachment.html From mkouba at redhat.com Thu Jun 8 03:23:29 2017 From: mkouba at redhat.com (Martin Kouba) Date: Thu, 8 Jun 2017 09:23:29 +0200 Subject: [cdi-dev] Proposal regarding CDI-705 In-Reply-To: References: Message-ID: <509613ed-fda3-a55e-5f17-5ac6a2d4eba7@redhat.com> Dne 7.6.2017 v 14:21 Antoine Sabot-Durand napsal(a): > Hi all, > > It seems that we introduced a mistake in CDI 2.0 regarding its alignment > with JTA. See https://issues.jboss.org/browse/CDI-705 > > Transactional observer bound to BEFORE_COMPLETION shouldn?t be triggered > if the transaction is rolled back or marked for roll back. > > I suggest that we skip the matching test in the TCK [1] and allow impl > to skip this rule and align on JTA. +1 > > JTA should be corrected in a coming MR. I suppose you mean "CDI should be corrected..." ;-) > > Thanks for your feedback > > > > Antoine > > > > > [1] https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From asabotdu at redhat.com Thu Jun 8 04:47:22 2017 From: asabotdu at redhat.com (Antoine Sabot-Durand) Date: Thu, 8 Jun 2017 10:47:22 +0200 Subject: [cdi-dev] Proposal regarding CDI-705 In-Reply-To: <509613ed-fda3-a55e-5f17-5ac6a2d4eba7@redhat.com> References: <509613ed-fda3-a55e-5f17-5ac6a2d4eba7@redhat.com> Message-ID: <9c243bbf-251b-450b-a896-664f5cb1f744@Spark> On 8 juin 2017 ? 09:23 +0200, Martin Kouba , wrote: > > Dne 7.6.2017 v 14:21 Antoine Sabot-Durand napsal(a): > > Hi all, > > > > It seems that we introduced a mistake in CDI 2.0 regarding its alignment > > with JTA. See https://issues.jboss.org/browse/CDI-705 > > > > Transactional observer bound to BEFORE_COMPLETION shouldn?t be triggered > > if the transaction is rolled back or marked for roll back. > > > > I suggest that we skip the matching test in the TCK [1] and allow impl > > to skip this rule and align on JTA. > > +1 > > > > > JTA should be corrected in a coming MR. > > I suppose you mean "CDI should be corrected..." ;-) Yes, Of course, CDI should be corrected ;) > > > > > Thanks for your feedback > > > > > > > > Antoine > > > > > > > > > > [1] https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/event/observer/transactional/roolback/TransactionalObserverRollbackTest.java > > > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170608/b6a24d34/attachment.html From issues at jboss.org Sun Jun 11 16:09:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sun, 11 Jun 2017 16:09:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-706) ProducerConfigurator has no method to configure the InjectionPoints In-Reply-To: References: Message-ID: Mark Struberg created CDI-706: --------------------------------- Summary: ProducerConfigurator has no method to configure the InjectionPoints Key: CDI-706 URL: https://issues.jboss.org/browse/CDI-706 Project: CDI Specification Issues Issue Type: Bug Reporter: Mark Struberg Producer has not only produce() and dispose() but also {noformat} Set getInjectionPoints() {noformat} But this information cannot be set with the ProducerConfigurator. So it is effectively not possible to properly create a Producer with this Configurator. Or did I miss some trick? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 02:46:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 12 Jun 2017 02:46:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-706) ProducerConfigurator has no method to configure the InjectionPoints In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419226#comment-13419226 ] Matej Novotny commented on CDI-706: ----------------------------------- Hey Mark, not sure you missed a trick, but I think you missed CDI-673. We purposely removed those methods for reasons described in the issue above. > ProducerConfigurator has no method to configure the InjectionPoints > ------------------------------------------------------------------- > > Key: CDI-706 > URL: https://issues.jboss.org/browse/CDI-706 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > > Producer has not only produce() and dispose() but also > {noformat} > Set getInjectionPoints() > {noformat} > But this information cannot be set with the ProducerConfigurator. > So it is effectively not possible to properly create a Producer with this Configurator. > Or did I miss some trick? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 02:51:00 2017 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Mon, 12 Jun 2017 02:51:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-706) ProducerConfigurator has no method to configure the InjectionPoints In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419230#comment-13419230 ] Matej Novotny commented on CDI-706: ----------------------------------- Also one more thing... bq. So it is effectively not possible to properly *create* a Producer with this Configurator. Yes, it not. Configurators were meant as a way to alter existing entities (producers in this case; only during {{ProcessProducer}}). If you wish to create a new one, I think {{BeanConfigurator}} is a better fit as there you define a way to produce such beans from scratch. > ProducerConfigurator has no method to configure the InjectionPoints > ------------------------------------------------------------------- > > Key: CDI-706 > URL: https://issues.jboss.org/browse/CDI-706 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > > Producer has not only produce() and dispose() but also > {noformat} > Set getInjectionPoints() > {noformat} > But this information cannot be set with the ProducerConfigurator. > So it is effectively not possible to properly create a Producer with this Configurator. > Or did I miss some trick? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 07:23:00 2017 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 13 Jun 2017 07:23:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-707) InjectionPointConfigurator #addQualifier etc does not define the @Default qualifier handling In-Reply-To: References: Message-ID: Mark Struberg created CDI-707: --------------------------------- Summary: InjectionPointConfigurator #addQualifier etc does not define the @Default qualifier handling Key: CDI-707 URL: https://issues.jboss.org/browse/CDI-707 Project: CDI Specification Issues Issue Type: Bug Reporter: Mark Struberg 3.8 defines the handling of @Default if no other qualifier is applied. So what happens if someone removes all Qualifiers? Or if someone adds some other Qualifier but still keep @Default around? We should clarify what happens in those cases. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 14 11:52:00 2017 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Wed, 14 Jun 2017 11:52:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-708) Serialization problems in section "1.3.1. JSF example". In-Reply-To: References: Message-ID: Martin Andersson created CDI-708: ------------------------------------ Summary: Serialization problems in section "1.3.1. JSF example". Key: CDI-708 URL: https://issues.jboss.org/browse/CDI-708 Project: CDI Specification Issues Issue Type: Bug Components: Concepts Affects Versions: 2.0 .Final Reporter: Martin Andersson Section "1.3.1. JSF example" provide an example of a class {{Login}}, that saves in its state an {{EntityManager}} reference and two {{Parameter}} references. The JPA specification does not say that a {{Parameter}} instance is serializable. This is also true for the {{EntityManager}} reference which is {{@Dependent}} (see section "1.3.3. Java EE component environment example"). JPA does not specify that the {{EntityManager}} is serializable and the EJB specification only specifies serialization semantics for passivation-enabled {{@Stateful}} EJB:s (which encourages the bean provider to not mark an {{EntityManager}} reference as transient, see EJB ?4.2.1). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 15 01:17:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 15 Jun 2017 01:17:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-708) Serialization problems in section "1.3.1. JSF example". In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421502#comment-13421502 ] Martin Kouba commented on CDI-708: ---------------------------------- Good catch! For the record, this also applies to {{CriteriaQuery query}} field and the resource bean for {{EntityManager}} is defined in 1.3.3 as {{@Dependent}}: {code:java} @Produces @PersistenceContext(unitName="UserData") @Users EntityManager userDatabaseEntityManager; {code} (in fact, containers are not required to support resources with scope other than {{@Dependent}}) > Serialization problems in section "1.3.1. JSF example". > ------------------------------------------------------- > > Key: CDI-708 > URL: https://issues.jboss.org/browse/CDI-708 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 2.0 .Final > Reporter: Martin Andersson > > Section "1.3.1. JSF example" provide an example of a class {{Login}}, that saves in its state an {{EntityManager}} reference and two {{Parameter}} references. > The JPA specification does not say that a {{Parameter}} instance is serializable. > This is also true for the {{EntityManager}} reference which is {{@Dependent}} (see section "1.3.3. Java EE component environment example"). JPA does not specify that the {{EntityManager}} is serializable and the EJB specification only specifies serialization semantics for passivation-enabled {{@Stateful}} EJB:s (which encourages the bean provider to not mark an {{EntityManager}} reference as transient, see EJB ?4.2.1). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 15 11:35:00 2017 From: issues at jboss.org (Martin Andersson (JIRA)) Date: Thu, 15 Jun 2017 11:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-708) Serialization problems in section "1.3.1. JSF example". In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421894#comment-13421894 ] Martin Andersson commented on CDI-708: -------------------------------------- Actually, CriteriaQuery is serializable. JPA 2.1, section "6.9 Query Execution": bq. CriteriaQuery, CriteriaUpdate, and CriteriaDelete objects must be serializable. > Serialization problems in section "1.3.1. JSF example". > ------------------------------------------------------- > > Key: CDI-708 > URL: https://issues.jboss.org/browse/CDI-708 > Project: CDI Specification Issues > Issue Type: Bug > Components: Concepts > Affects Versions: 2.0 .Final > Reporter: Martin Andersson > > Section "1.3.1. JSF example" provide an example of a class {{Login}}, that saves in its state an {{EntityManager}} reference and two {{Parameter}} references. > The JPA specification does not say that a {{Parameter}} instance is serializable. > This is also true for the {{EntityManager}} reference which is {{@Dependent}} (see section "1.3.3. Java EE component environment example"). JPA does not specify that the {{EntityManager}} is serializable and the EJB specification only specifies serialization semantics for passivation-enabled {{@Stateful}} EJB:s (which encourages the bean provider to not mark an {{EntityManager}} reference as transient, see EJB ?4.2.1). -- This message was sent by Atlassian JIRA (v7.2.3#72005)