From issues at jboss.org Mon Jul 1 02:29:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 1 Jul 2019 02:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3159) LRA does not work for JAX-RS resources which are not root resource classes In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3159: ------------------------------------- Summary: LRA does not work for JAX-RS resources which are not root resource classes Key: JBTM-3159 URL: https://issues.jboss.org/browse/JBTM-3159 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Martin Stefanko Assignee: Martin Stefanko When JAX-RS LRA participant is not a root resource class the compensation/completion methods are not called because the constructed path is taken from the string value of the root resource @Path annotation. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 1 02:36:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 1 Jul 2019 02:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3159) LRA does not work for JAX-RS resources which are not root resource classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3159: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1463 > LRA does not work for JAX-RS resources which are not root resource classes > -------------------------------------------------------------------------- > > Key: JBTM-3159 > URL: https://issues.jboss.org/browse/JBTM-3159 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > When JAX-RS LRA participant is not a root resource class the compensation/completion methods are not called because the constructed path is taken from the string value of the root resource @Path annotation. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 1 08:45:00 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Mon, 1 Jul 2019 08:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3157) LRA participant does not respect JAX-RS path definitions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754032#comment-13754032 ] Thomas Jenkinson commented on JBTM-3157: ---------------------------------------- See https://docs.oracle.com/javaee/7/api/javax/ws/rs/Path.html which indicates the initial slash can be ignored > LRA participant does not respect JAX-RS path definitions > -------------------------------------------------------- > > Key: JBTM-3157 > URL: https://issues.jboss.org/browse/JBTM-3157 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > When LRA participant defines paths for participant methods like this: > {code:java} > @PUT > @Path("compensate") > @Compensate > public void compensate(@HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > instead of: > {code:java} > @PUT > @Path("/compensate") > @Compensate > public void compensate(@HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > The participant methods are never executed because the constructed URL is not valid. However, even the first code snippet is still a valid JAX-RS resource definition and thus it should be respected. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Jul 12 06:01:00 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Fri, 12 Jul 2019 06:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3150) Upgrade the version of maven that we use to build with and migrate from swarm to thorntail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Jenkinson updated JBTM-3150: ----------------------------------- Summary: Upgrade the version of maven that we use to build with and migrate from swarm to thorntail (was: Upgrade the version of maven that we use to build with) > Upgrade the version of maven that we use to build with and migrate from swarm to thorntail > ------------------------------------------------------------------------------------------ > > Key: JBTM-3150 > URL: https://issues.jboss.org/browse/JBTM-3150 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Narayana builds with version 3.3.9 of maven. This version is quite old and does not work with containers such as thorntail and quarkus. This JIRA is to upgrade our build to use version 3.6.1 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Jul 23 04:47:00 2019 From: issues at jboss.org (Matej Kralik (Jira)) Date: Tue, 23 Jul 2019 04:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3160) Start LRA returns first URI all the time In-Reply-To: References: Message-ID: Matej Kralik created JBTM-3160: ---------------------------------- Summary: Start LRA returns first URI all the time Key: JBTM-3160 URL: https://issues.jboss.org/browse/JBTM-3160 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Reporter: Matej Kralik Assignee: Michael Musgrove Attachments: reporoducer-source.zip, reproducer.jar The function {code:java}lraNarayanaLRAClient.startLRA(...){code} doesn't return the new URI but the URI of the first transaction all the time even though the first transaction is already closed. This happens only with coordinator 5.9.6-SNAPSHOT. For coordinator 5.9.5-Final, the function returns new URI all the time. So when I run this code more times, the function returns the same URI all the time. In the second iteration, the URI which is returned from the startLRA() is the same as in the first iteration. That transaction is already closed so the closeLRA() failed. {code:java} for (int i = 0; i < 10; i++) { URI uri = null; uri = lraClient.startLRA(getClass().getCanonicalName() + i); lraClient.closeLRA(uri); } {code} I uploaded reproducer for it. It is spring boot application which compares returned URI from the startLRA() and the URI which is on the `http://localhost:8080/lra-coordinator` For debugging, just import source project to IDE (I use Intelij IDEA) and run/debug _TestingApplication_. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Jul 23 18:09:00 2019 From: issues at jboss.org (Matej Kralik (Jira)) Date: Tue, 23 Jul 2019 18:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application In-Reply-To: References: Message-ID: Matej Kralik created JBTM-3161: ---------------------------------- Summary: Nested LRA doesn't start in the Spring Boot + JAX-RS application Key: JBTM-3161 URL: https://issues.jboss.org/browse/JBTM-3161 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Matej Kralik Attachments: flight.zip For demonstrating purpose, I migrated flight service from [narayana quickstart|https://github.com/jbosstm/quickstart/tree/master/rts/lra/flight-service] to the Spring Boot application and uploaded it to the attachment. When I stop debugger in the original swarm flight service (FlightParticipant [line 64|https://github.com/jbosstm/quickstart/blob/3b848517086c2abc32bff6895b2972fa38ea6db9/rts/lra/flight-service/src/main/java/io/narayana/rts/lra/demo/flight/FlightParticipant.java#L65]), the *_ at HeaderParam(LRA_HTTP_CONTEXT_HEADER) String lraId_*, is new for that service. When I stop debugger in the SpringBoot+JAX-RS, the lraId is the same as for a parent. It looks that the _ServerLRAFilter_ doesn't start the new LRA. I add a breakpoint to the *_ServerLRAFilter.filter(...)_* to see when the filter is applied and create new LRA before the JAX-RS method. When I call original swarm flight service, the filter is used however when I call SpringBoot flight service, the filter is not used so it looks that the filter is not used at all in the SpringBoot+JAX-RS application. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 24 10:09:01 2019 From: issues at jboss.org (Ariel Carrera (Jira)) Date: Wed, 24 Jul 2019 10:09:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3162) Remove superfluous double check at validTransaction method In-Reply-To: References: Message-ID: Ariel Carrera created JBTM-3162: ----------------------------------- Summary: Remove superfluous double check at validTransaction method Key: JBTM-3162 URL: https://issues.jboss.org/browse/JBTM-3162 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transactional Driver Affects Versions: 5.9.5.Final Reporter: Ariel Carrera There is a superfluous check at BaseTransactionalDriverXAConnection.validTransaction method. {code:java} public final boolean validTransaction(javax.transaction.Transaction tx) { boolean valid = true; if (_theTransaction != null) { valid = _theTransaction.equals(tx); * if (!valid) { valid = _theTransaction.equals(tx); } * } return valid; } {code} link: [github|https://github.com/jbosstm/narayana/blob/9f42d45b664483c9f0e17cb20122c1d5436ba856/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/BaseTransactionalDriverXAConnection.java#L81] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 24 10:31:01 2019 From: issues at jboss.org (Ariel Carrera (Jira)) Date: Wed, 24 Jul 2019 10:31:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3162) Remove superfluous double check at validTransaction method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762914#comment-13762914 ] Ariel Carrera commented on JBTM-3162: ------------------------------------- I created the ticket and committed changes in a fork. Tell me if you need a junit test for these little lines removed that doesn't change any function. > Remove superfluous double check at validTransaction method > ---------------------------------------------------------- > > Key: JBTM-3162 > URL: https://issues.jboss.org/browse/JBTM-3162 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.9.5.Final > Reporter: Ariel Carrera > Priority: Trivial > > There is a superfluous check at BaseTransactionalDriverXAConnection.validTransaction method. > {code:java} > public final boolean validTransaction(javax.transaction.Transaction tx) { > boolean valid = true; > if (_theTransaction != null) { > valid = _theTransaction.equals(tx); > * if (!valid) { > valid = _theTransaction.equals(tx); > } * > } > return valid; > } > {code} > link: > [github|https://github.com/jbosstm/narayana/blob/9f42d45b664483c9f0e17cb20122c1d5436ba856/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/BaseTransactionalDriverXAConnection.java#L81] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 24 10:32:00 2019 From: issues at jboss.org (Ariel Carrera (Jira)) Date: Wed, 24 Jul 2019 10:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3162) Remove superfluous double check at validTransaction method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762914#comment-13762914 ] Ariel Carrera edited comment on JBTM-3162 at 7/24/19 10:31 AM: --------------------------------------------------------------- I committed the changes in a fork. Tell me if you need a junit test for these little lines removed that doesn't change any function. was (Author: arielcarrera): I created the ticket and committed changes in a fork. Tell me if you need a junit test for these little lines removed that doesn't change any function. > Remove superfluous double check at validTransaction method > ---------------------------------------------------------- > > Key: JBTM-3162 > URL: https://issues.jboss.org/browse/JBTM-3162 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.9.5.Final > Reporter: Ariel Carrera > Priority: Trivial > > There is a superfluous check at BaseTransactionalDriverXAConnection.validTransaction method. > {code:java} > public final boolean validTransaction(javax.transaction.Transaction tx) { > boolean valid = true; > if (_theTransaction != null) { > valid = _theTransaction.equals(tx); > * if (!valid) { > valid = _theTransaction.equals(tx); > } * > } > return valid; > } > {code} > link: > [github|https://github.com/jbosstm/narayana/blob/9f42d45b664483c9f0e17cb20122c1d5436ba856/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/BaseTransactionalDriverXAConnection.java#L81] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 24 11:22:00 2019 From: issues at jboss.org (Thomas Jenkinson (Jira)) Date: Wed, 24 Jul 2019 11:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3162) Remove superfluous double check at validTransaction method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762954#comment-13762954 ] Thomas Jenkinson commented on JBTM-3162: ---------------------------------------- Thanks, please can you raise a PR for it over here: https://github.com/jbosstm/narayana/pulls > Remove superfluous double check at validTransaction method > ---------------------------------------------------------- > > Key: JBTM-3162 > URL: https://issues.jboss.org/browse/JBTM-3162 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.9.5.Final > Reporter: Ariel Carrera > Priority: Trivial > > There is a superfluous check at BaseTransactionalDriverXAConnection.validTransaction method. > {code:java} > public final boolean validTransaction(javax.transaction.Transaction tx) { > boolean valid = true; > if (_theTransaction != null) { > valid = _theTransaction.equals(tx); > * if (!valid) { > valid = _theTransaction.equals(tx); > } * > } > return valid; > } > {code} > link: > [github|https://github.com/jbosstm/narayana/blob/9f42d45b664483c9f0e17cb20122c1d5436ba856/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/BaseTransactionalDriverXAConnection.java#L81] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 24 13:51:00 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Wed, 24 Jul 2019 13:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3162) Remove superfluous double check at validTransaction method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ariel Carrera created pull request #1467 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Remove superfluous double check at validTransaction method > ---------------------------------------------------------- > > Key: JBTM-3162 > URL: https://issues.jboss.org/browse/JBTM-3162 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.9.5.Final > Reporter: Ariel Carrera > Priority: Trivial > > There is a superfluous check at BaseTransactionalDriverXAConnection.validTransaction method. > {code:java} > public final boolean validTransaction(javax.transaction.Transaction tx) { > boolean valid = true; > if (_theTransaction != null) { > valid = _theTransaction.equals(tx); > * if (!valid) { > valid = _theTransaction.equals(tx); > } * > } > return valid; > } > {code} > link: > [github|https://github.com/jbosstm/narayana/blob/9f42d45b664483c9f0e17cb20122c1d5436ba856/ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/BaseTransactionalDriverXAConnection.java#L81] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Sun Jul 28 06:20:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Sun, 28 Jul 2019 06:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3163: ------------------------------------- Summary: AfterLRA notifications are delivered twice Key: JBTM-3163 URL: https://issues.jboss.org/browse/JBTM-3163 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Affects Versions: 5.9.5.Final Reporter: Martin Stefanko Assignee: Martin Stefanko @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Sun Jul 28 09:03:00 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Sun, 28 Jul 2019 09:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Martin Stefanko created pull request #1468 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 01:43:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 01:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?focusedWorklogId=12447543&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12447543 ] Martin Stefanko logged work on JBTM-3163: ----------------------------------------- Author: Martin Stefanko Created on: 29/Jul/19 1:42 AM Start Date: 29/Jul/19 1:42 AM Worklog Time Spent: 1 hour Issue Time Tracking ------------------- Remaining Estimate: 0 minutes (was: 1 hour) Time Spent: 1 hour Worklog Id: (was: 12447543) > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 03:39:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 03:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3163: ---------------------------------- Description: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. was: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 03:40:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 03:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3163: ---------------------------------- Description: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450] was: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450] -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 03:41:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 03:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3163: ---------------------------------- Description: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) was: @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450] > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 03:53:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 03:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764034#comment-13764034 ] Martin Stefanko commented on JBTM-3163: --------------------------------------- In [LRAService|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java] we have currently in the method [endLRA()|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L231] calls: * on line [241|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L241] - transaction.end() which calls -> [`Transaction#doEnd`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L351] which on line [444|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L444] calls [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] * on line [250|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L250] - call to [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] again [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] makes the final AfterLRA calls on line [152|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L152] > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 03:54:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 03:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764034#comment-13764034 ] Martin Stefanko edited comment on JBTM-3163 at 7/29/19 3:53 AM: ---------------------------------------------------------------- In [LRAService|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java] we have currently in the method [endLRA()|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L231] calls: * on line [241|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L241] - transaction.end() which calls -> [Transaction#doEnd|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L351] which on line [444|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L444] calls [LRAService#finished|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] * on line [250|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L250] - call to [LRAService#finished|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] again [LRAService#finished|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] makes the final AfterLRA calls on line [152|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L152] was (Author: mstefank): In [LRAService|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java] we have currently in the method [endLRA()|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L231] calls: * on line [241|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L241] - transaction.end() which calls -> [`Transaction#doEnd`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L351] which on line [444|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L444] calls [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] * on line [250|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L250] - call to [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] again [`LRAService#finished`|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L145] makes the final AfterLRA calls on line [152|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/service/LRAService.java#L152] > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 05:23:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Mon, 29 Jul 2019 05:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764084#comment-13764084 ] Michael Musgrove commented on JBTM-3163: ---------------------------------------- bq. The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished Doesn't this mean the test is wrong (or the spec is wrong for not being explicit here). The semantics are "at least once" so multiple attempts to deliver the notification should be allowed since delivery is not always guaranteed in an HTTP environment. We can fix the code so that it only delivers the notification once on each recovery pass but it is not Major priority. > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jul 29 05:26:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 29 Jul 2019 05:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3163) AfterLRA notifications are delivered twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764085#comment-13764085 ] Martin Stefanko commented on JBTM-3163: --------------------------------------- [~mmusgrov] This blocks the work on non-JAX-RS participants implementation so I think Major priority is appropriate. > AfterLRA notifications are delivered twice > ------------------------------------------ > > Key: JBTM-3163 > URL: https://issues.jboss.org/browse/JBTM-3163 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Original Estimate: 1 hour > Time Spent: 1 hour > Remaining Estimate: 0 minutes > > @AfterLRA notifications recently introduced in the specification are being delivered twice when the LRA is finished. > There is actually a TCK test testing this for non JAX-RS participant so this is blocking [PR 1450|https://github.com/jbosstm/narayana/pull/1450]. > The failing TCK test `TckParticipantTests#validWebApplicationExceptionReturnedTest` asserts now that `@AfterLRA` method is called once after the LRA is finished - https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckParticipantTests.java#L82. This means that the specification prohibits that AfterLRA method is called more than once for one LRA. > This isn't failing current TCK as the assert is present in the non-JAX-RS TCK ([PR 1450|https://github.com/jbosstm/narayana/pull/1450]) -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 04:46:00 2019 From: issues at jboss.org (Matej Kralik (Jira)) Date: Wed, 31 Jul 2019 04:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Kralik updated JBTM-3161: ------------------------------- Component/s: LRA > Nested LRA doesn't start in the Spring Boot + JAX-RS application > ---------------------------------------------------------------- > > Key: JBTM-3161 > URL: https://issues.jboss.org/browse/JBTM-3161 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Matej Kralik > Priority: Critical > Attachments: flight.zip > > > For demonstrating purpose, I migrated flight service from [narayana quickstart|https://github.com/jbosstm/quickstart/tree/master/rts/lra/flight-service] to the Spring Boot application and uploaded it to the attachment. > When I stop debugger in the original swarm flight service (FlightParticipant [line 64|https://github.com/jbosstm/quickstart/blob/3b848517086c2abc32bff6895b2972fa38ea6db9/rts/lra/flight-service/src/main/java/io/narayana/rts/lra/demo/flight/FlightParticipant.java#L65]), the *_ at HeaderParam(LRA_HTTP_CONTEXT_HEADER) String lraId_*, is new for that service. When I stop debugger in the SpringBoot+JAX-RS, the lraId is the same as for a parent. It looks that the _ServerLRAFilter_ doesn't start the new LRA. > I add a breakpoint to the *_ServerLRAFilter.filter(...)_* to see when the filter is applied and create new LRA before the JAX-RS method. When I call original swarm flight service, the filter is used however when I call SpringBoot flight service, the filter is not used so it looks that the filter is not used at all in the SpringBoot+JAX-RS application. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 10:11:01 2019 From: issues at jboss.org (Ondrej Chaloupka (Jira)) Date: Wed, 31 Jul 2019 10:11:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3164) RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary In-Reply-To: References: Message-ID: Ondrej Chaloupka created JBTM-3164: -------------------------------------- Summary: RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary Key: JBTM-3164 URL: https://issues.jboss.org/browse/JBTM-3164 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.9.5.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka The current definition of {{pom.xml}} for {{rts/sra}} project defines the dependency on all microprofile fractions from Thorntail. It depends on fractions which are not used in the project. This makes the result jar bigger than necessary (it's 81MB big). The definition should consider only fractions which are about to be used in the project and thus the result jar could be around 60MB. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 10:13:01 2019 From: issues at jboss.org (Ondrej Chaloupka (Jira)) Date: Wed, 31 Jul 2019 10:13:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3164) RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondrej Chaloupka created pull request #1470 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary > ------------------------------------------------------------------------------------------------------- > > Key: JBTM-3164 > URL: https://issues.jboss.org/browse/JBTM-3164 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > The current definition of {{pom.xml}} for {{rts/sra}} project defines the dependency on all microprofile fractions from Thorntail. It depends on fractions which are not used in the project. This makes the result jar bigger than necessary (it's 81MB big). > The definition should consider only fractions which are about to be used in the project and thus the result jar could be around 60MB. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 10:28:00 2019 From: issues at jboss.org (Ondrej Chaloupka (Jira)) Date: Wed, 31 Jul 2019 10:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3164) RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Chaloupka updated JBTM-3164: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1470 > RTS SRA uses too more dependencies than needed and causes the thorntail jar being bigger than necessary > ------------------------------------------------------------------------------------------------------- > > Key: JBTM-3164 > URL: https://issues.jboss.org/browse/JBTM-3164 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > The current definition of {{pom.xml}} for {{rts/sra}} project defines the dependency on all microprofile fractions from Thorntail. It depends on fractions which are not used in the project. This makes the result jar bigger than necessary (it's 81MB big). > The definition should consider only fractions which are about to be used in the project and thus the result jar could be around 60MB. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 11:22:02 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 31 Jul 2019 11:22:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3165) Don't create the EnumSet and TransactionEvent unless it is required In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3165: -------------------------------------- Summary: Don't create the EnumSet and TransactionEvent unless it is required Key: JBTM-3165 URL: https://issues.jboss.org/browse/JBTM-3165 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTS Affects Versions: 5.9.5.Final Reporter: Michael Musgrove Assignee: Stuart Douglas Fix For: 5.next The TransactionManager (https://github.com/jbosstm/narayana/pull/1469/files#diff-198455dd7f41f7bce18173479e68b493) contains code to notify listeners of the transaction lifecycle which can be improved from a performance perspective. In particular its use of an EnumSet can be improved. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 11:48:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 31 Jul 2019 11:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3165) Don't create the EnumSet and TransactionEvent unless it is required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3165: ----------------------------------- Status: Pull Request Sent (was: Open) > Don't create the EnumSet and TransactionEvent unless it is required > ------------------------------------------------------------------- > > Key: JBTM-3165 > URL: https://issues.jboss.org/browse/JBTM-3165 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Stuart Douglas > Priority: Minor > Fix For: 5.next > > > The TransactionManager (https://github.com/jbosstm/narayana/pull/1469/files#diff-198455dd7f41f7bce18173479e68b493) contains code to notify listeners of the transaction lifecycle which can be improved from a performance perspective. In particular its use of an EnumSet can be improved. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 11:49:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 31 Jul 2019 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3165) Don't create the EnumSet and TransactionEvent unless it is required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3165: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Don't create the EnumSet and TransactionEvent unless it is required > ------------------------------------------------------------------- > > Key: JBTM-3165 > URL: https://issues.jboss.org/browse/JBTM-3165 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Stuart Douglas > Priority: Minor > Fix For: 5.next > > > The TransactionManager (https://github.com/jbosstm/narayana/pull/1469/files#diff-198455dd7f41f7bce18173479e68b493) contains code to notify listeners of the transaction lifecycle which can be improved from a performance perspective. In particular its use of an EnumSet can be improved. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 13:45:00 2019 From: issues at jboss.org (Stuart Douglas (Jira)) Date: Wed, 31 Jul 2019 13:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3166) TransactionListener's should not be enabled by default In-Reply-To: References: Message-ID: Stuart Douglas created JBTM-3166: ------------------------------------ Summary: TransactionListener's should not be enabled by default Key: JBTM-3166 URL: https://issues.jboss.org/browse/JBTM-3166 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Stuart Douglas They have a performance cost, are deprecated, and nothing in WildFly uses them. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 13:55:00 2019 From: issues at jboss.org (Stuart Douglas (Jira)) Date: Wed, 31 Jul 2019 13:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3166) TransactionListener's should not be enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Stuart Douglas created pull request #1472 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > TransactionListener's should not be enabled by default > ------------------------------------------------------ > > Key: JBTM-3166 > URL: https://issues.jboss.org/browse/JBTM-3166 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Stuart Douglas > Priority: Major > > They have a performance cost, are deprecated, and nothing in WildFly uses them. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 15:55:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Wed, 31 Jul 2019 15:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3165) Don't create the EnumSet and TransactionEvent unless it is required In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3165: ---------------------------------- Labels: downstream_dependency (was: ) > Don't create the EnumSet and TransactionEvent unless it is required > ------------------------------------------------------------------- > > Key: JBTM-3165 > URL: https://issues.jboss.org/browse/JBTM-3165 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Stuart Douglas > Priority: Minor > Labels: downstream_dependency > Fix For: 5.next > > > The TransactionManager (https://github.com/jbosstm/narayana/pull/1469/files#diff-198455dd7f41f7bce18173479e68b493) contains code to notify listeners of the transaction lifecycle which can be improved from a performance perspective. In particular its use of an EnumSet can be improved. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Jul 31 15:56:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Wed, 31 Jul 2019 15:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3166) TransactionListener's should not be enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3166: ---------------------------------- Labels: downstream_dependency (was: ) > TransactionListener's should not be enabled by default > ------------------------------------------------------ > > Key: JBTM-3166 > URL: https://issues.jboss.org/browse/JBTM-3166 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Stuart Douglas > Priority: Major > Labels: downstream_dependency > > They have a performance cost, are deprecated, and nothing in WildFly uses them. -- This message was sent by Atlassian Jira (v7.12.1#712002)