From issues at jboss.org Mon Oct 2 13:25:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 2 Oct 2017 13:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2935) Make LRA @Complete optional In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2935: -------------------------------------- Summary: Make LRA @Complete optional Key: JBTM-2935 URL: https://issues.jboss.org/browse/JBTM-2935 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next LRA compensators currently require both @Complete and @Compensate annotations to be present. The @Complete should be optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 2 13:29:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 2 Oct 2017 13:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2935) Make LRA @Complete optional In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1225 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Make LRA @Complete optional > --------------------------- > > Key: JBTM-2935 > URL: https://issues.jboss.org/browse/JBTM-2935 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > LRA compensators currently require both @Complete and @Compensate annotations to be present. The @Complete should be optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 2 13:58:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 2 Oct 2017 13:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2936: -------------------------------------- Summary: JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id Key: JBTM-2936 URL: https://issues.jboss.org/browse/JBTM-2936 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 2 14:04:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 2 Oct 2017 14:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2936: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1222 > JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id > ------------------------------------------------------------------------------------ > > Key: JBTM-2936 > URL: https://issues.jboss.org/browse/JBTM-2936 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Oct 3 06:58:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 3 Oct 2017 06:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2937) Do not recommend "X-" prefixed headers In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2937: -------------------------------------- Summary: Do not recommend "X-" prefixed headers Key: JBTM-2937 URL: https://issues.jboss.org/browse/JBTM-2937 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Quote from PR https://github.com/jbosstm/microprofile-sandbox/pull/3 raised by @nicolaferraro : {quote} A small change to the spec in order to use "Long-Running-Action" and "Short-Running-Action" headers instead of "X-lra" and "X-sra". "X-" prefixed headers should be deprecated by RFC-6648 and RFC-7231. They are not mandated by this spec, but they'll be used by microprofile rest services, so it's important for other technologies to use them if they want to build interoperable rest services. {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Oct 3 07:00:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 3 Oct 2017 07:00:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2935) Make LRA @Complete optional In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2935: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make LRA @Complete optional > --------------------------- > > Key: JBTM-2935 > URL: https://issues.jboss.org/browse/JBTM-2935 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > LRA compensators currently require both @Complete and @Compensate annotations to be present. The @Complete should be optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Oct 4 13:33:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 4 Oct 2017 13:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2938) LRA participant complete/compensate methods should use HTTP PUT In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2938: -------------------------------------- Summary: LRA participant complete/compensate methods should use HTTP PUT Key: JBTM-2938 URL: https://issues.jboss.org/browse/JBTM-2938 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later LRA participant complete and compensate methods are currently called using an HTTP POST request. Since these methods should be idempotent they should respond to PUT since in a REST based system PUT is idempotent and POST is not. Both the implementation and the specification need changing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Oct 5 05:03:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 5 Oct 2017 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2939: ------------------------------------- Summary: JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA Key: JBTM-2939 URL: https://issues.jboss.org/browse/JBTM-2939 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTS Affects Versions: 5.7.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Oct 5 05:04:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 5 Oct 2017 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2939: ---------------------------------- Description: JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. was: JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Oct 5 05:42:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 5 Oct 2017 05:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2940) LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2940: -------------------------------------- Summary: LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status Key: JBTM-2940 URL: https://issues.jboss.org/browse/JBTM-2940 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The compensate and complete participant endpoints are allowed to return `202 Accepted` if they cannot complete the operation immediately in which case they should either return a status URL in the HTTP Location Header of the response or the resource class should contain a method annotated with @Status. Recovery should then periodically probe the status and clean up once the status indicates that the participant has completed or compensated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Oct 7 11:05:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 7 Oct 2017 11:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2937) Do not recommend "X-" prefixed headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1226 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Do not recommend "X-" prefixed headers > -------------------------------------- > > Key: JBTM-2937 > URL: https://issues.jboss.org/browse/JBTM-2937 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Quote from PR https://github.com/jbosstm/microprofile-sandbox/pull/3 raised by @nicolaferraro : > {quote} > A small change to the spec in order to use "Long-Running-Action" and "Short-Running-Action" headers instead of "X-lra" and "X-sra". > "X-" prefixed headers should be deprecated by RFC-6648 and RFC-7231. > They are not mandated by this spec, but they'll be used by microprofile rest services, so it's important for other technologies to use them if they want to build interoperable rest services. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sat Oct 7 12:57:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 7 Oct 2017 12:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2940) LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1227 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2940 > URL: https://issues.jboss.org/browse/JBTM-2940 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The compensate and complete participant endpoints are allowed to return `202 Accepted` if they cannot complete the operation immediately in which case they should either return a status URL in the HTTP Location Header of the response or the resource class should contain a method annotated with @Status. > Recovery should then periodically probe the status and clean up once the status indicates that the participant has completed or compensated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Oct 8 18:40:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 8 Oct 2017 18:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2941) Support JAX-RS unaware LRA participants In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2941: -------------------------------------- Summary: Support JAX-RS unaware LRA participants Key: JBTM-2941 URL: https://issues.jboss.org/browse/JBTM-2941 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA proposal includes a Java based compensation registration API to support those applications that cannot directly expose JAX-RS endpoints for compensation activities. This JIRA adds a reference implementation of that API. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 9 04:05:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 9 Oct 2017 04:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2942: ------------------------------- Summary: LRA tests failed when building with the JDK9 Key: JBTM-2942 URL: https://issues.jboss.org/browse/JBTM-2942 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Amos Feng Assignee: Amos Feng The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-crash-with-java-9 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-while-starting-wildfly-swarm-provided-custom-main-meth -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 9 05:25:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 05:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2941) Support JAX-RS unaware LRA participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1228 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Support JAX-RS unaware LRA participants > --------------------------------------- > > Key: JBTM-2941 > URL: https://issues.jboss.org/browse/JBTM-2941 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The LRA proposal includes a Java based compensation registration API to support those applications that cannot directly expose JAX-RS endpoints for compensation activities. This JIRA adds a reference implementation of that API. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 9 08:54:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 9 Oct 2017 08:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2942: -------------------------------- Labels: jdk9 (was: ) > LRA tests failed when building with the JDK9 > -------------------------------------------- > > Key: JBTM-2942 > URL: https://issues.jboss.org/browse/JBTM-2942 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > > The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. > 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-crash-with-java-9 > 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-while-starting-wildfly-swarm-provided-custom-main-meth -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Oct 9 10:45:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2940) LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2940: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2940 > URL: https://issues.jboss.org/browse/JBTM-2940 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The compensate and complete participant endpoints are allowed to return `202 Accepted` if they cannot complete the operation immediately in which case they should either return a status URL in the HTTP Location Header of the response or the resource class should contain a method annotated with @Status. > Recovery should then periodically probe the status and clean up once the status indicates that the participant has completed or compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 9 10:46:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2937) Do not recommend "X-" prefixed headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2937: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Resolved by PR https://github.com/jbosstm/narayana/pull/1227 > Do not recommend "X-" prefixed headers > -------------------------------------- > > Key: JBTM-2937 > URL: https://issues.jboss.org/browse/JBTM-2937 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Quote from PR https://github.com/jbosstm/microprofile-sandbox/pull/3 raised by @nicolaferraro : > {quote} > A small change to the spec in order to use "Long-Running-Action" and "Short-Running-Action" headers instead of "X-lra" and "X-sra". > "X-" prefixed headers should be deprecated by RFC-6648 and RFC-7231. > They are not mandated by this spec, but they'll be used by microprofile rest services, so it's important for other technologies to use them if they want to build interoperable rest services. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 9 10:48:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2938) LRA participant complete/compensate methods should use HTTP PUT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2938: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1227 > LRA participant complete/compensate methods should use HTTP PUT > --------------------------------------------------------------- > > Key: JBTM-2938 > URL: https://issues.jboss.org/browse/JBTM-2938 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > LRA participant complete and compensate methods are currently called using an HTTP POST request. Since these methods should be idempotent they should respond to PUT since in a REST based system PUT is idempotent and POST is not. > Both the implementation and the specification need changing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 9 10:48:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2938) LRA participant complete/compensate methods should use HTTP PUT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2938: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA participant complete/compensate methods should use HTTP PUT > --------------------------------------------------------------- > > Key: JBTM-2938 > URL: https://issues.jboss.org/browse/JBTM-2938 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > LRA participant complete and compensate methods are currently called using an HTTP POST request. Since these methods should be idempotent they should respond to PUT since in a REST based system PUT is idempotent and POST is not. > Both the implementation and the specification need changing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 9 10:49:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2934) LRA nested and parent coordinators should optimise calls when in a single VM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2934: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA nested and parent coordinators should optimise calls when in a single VM > ---------------------------------------------------------------------------- > > Key: JBTM-2934 > URL: https://issues.jboss.org/browse/JBTM-2934 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Application Server Integration, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > LRA nested and parent coordinators use JAX-RS requests to driver the LRA protocol. When the two coordinators are in the same JVM direct jave method calls should be used. > The need for this enhancement is to support running on OpenShift. A secondary benefit is performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 9 10:55:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 9 Oct 2017 10:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2936: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id > ------------------------------------------------------------------------------------ > > Key: JBTM-2936 > URL: https://issues.jboss.org/browse/JBTM-2936 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 06:10:02 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 10 Oct 2017 06:10:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2943: ----------------------------------- Summary: Remove ability for participants to return business logic from their completion handlers Key: JBTM-2943 URL: https://issues.jboss.org/browse/JBTM-2943 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 06:10:02 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 10 Oct 2017 06:10:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2943: ----------------------------------- Assignee: Michael Musgrove > Remove ability for participants to return business logic from their completion handlers > --------------------------------------------------------------------------------------- > > Key: JBTM-2943 > URL: https://issues.jboss.org/browse/JBTM-2943 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 06:10:02 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 10 Oct 2017 06:10:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2943: -------------------------------- Component/s: LRA > Remove ability for participants to return business logic from their completion handlers > --------------------------------------------------------------------------------------- > > Key: JBTM-2943 > URL: https://issues.jboss.org/browse/JBTM-2943 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 08:16:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 10 Oct 2017 08:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1229 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 08:16:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 10 Oct 2017 08:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1229 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 08:17:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 10 Oct 2017 08:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2939 started by Ondra Chaloupka. --------------------------------------------- > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 10 10:35:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 10 Oct 2017 10:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474696#comment-13474696 ] Michael Musgrove commented on JBTM-2939: ---------------------------------------- Just to add some clarification: since recovery is handling the transaction there must be a log for it which in turn means that the prepare phase has ended and a decision has been made to commit the transaction. Now since a resource is not allowed to forget a heuristic decision and since the resource no longer has record of the xid it is safe to infer that the resource has indeed successfully committed its branch (ie from the TM's point of view this is not a heuristic). > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 11 04:42:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 11 Oct 2017 04:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475149#comment-13475149 ] Ondra Chaloupka commented on JBTM-2939: --------------------------------------- Yes, that's how I understand the case and how I expect this should be handled. > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 11 04:42:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 11 Oct 2017 04:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2939: ---------------------------------- Comment: was deleted (was: Yes, that's how I understand the case and how I expect this should be handled.) > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 11 07:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 11 Oct 2017 07:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2915) Let NarayanaJtaServletContextListener be deployed without need for web.xml change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2915: -------------------------------- Fix Version/s: 5.6.3.Final (was: 5.next) > Let NarayanaJtaServletContextListener be deployed without need for web.xml change > --------------------------------------------------------------------------------- > > Key: JBTM-2915 > URL: https://issues.jboss.org/browse/JBTM-2915 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.3.Final > > > Currently you need a web.xml with the listener in it but if you annotate the class with javax.servlet.annotation.WebListener it will deploy automatically. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 11 07:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 11 Oct 2017 07:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2915) Let NarayanaJtaServletContextListener be deployed without need for web.xml change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2915. ------------------------------- Resolution: Done > Let NarayanaJtaServletContextListener be deployed without need for web.xml change > --------------------------------------------------------------------------------- > > Key: JBTM-2915 > URL: https://issues.jboss.org/browse/JBTM-2915 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.3.Final > > > Currently you need a web.xml with the listener in it but if you annotate the class with javax.servlet.annotation.WebListener it will deploy automatically. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 13 04:35:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 13 Oct 2017 04:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476698#comment-13476698 ] Ondra Chaloupka commented on JBTM-2932: --------------------------------------- hi [~mmusgrov], I would like just check with you if this is still an issue? I wasn't able to simulate this on my machine and haven't seen it on CI either. Thanks. > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 13 05:56:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Oct 2017 05:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) More specification updates In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2944: -------------------------------------- Summary: More specification updates Key: JBTM-2944 URL: https://issues.jboss.org/browse/JBTM-2944 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. 5. Remove the interface method for starting an LRA {code} URL startLRA(String clientID, Long timeout) throws GenericLRAException; {code} since it is superfluous - just use the one that takes a timeunit instead: {code} URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 13 08:00:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Oct 2017 08:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) LRA specification updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2944: ----------------------------------- Summary: LRA specification updates (was: More specification updates) > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 5. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 13 08:01:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Oct 2017 08:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) LRA specification updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1231 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 5. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 13 10:45:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Oct 2017 10:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) LRA specification updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2944: ----------------------------------- Description: The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. 2. Terminating an LRA MAY return the status of the LRA. 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. 6. Remove the interface method for starting an LRA {code} URL startLRA(String clientID, Long timeout) throws GenericLRAException; {code} since it is superfluous - just use the one that takes a timeunit instead: {code} URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; {code} was: The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. 5. Remove the interface method for starting an LRA {code} URL startLRA(String clientID, Long timeout) throws GenericLRAException; {code} since it is superfluous - just use the one that takes a timeunit instead: {code} URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; {code} > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Terminating an LRA MAY return the status of the LRA. > 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 6. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 15:03:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Oct 2017 15:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) LRA specification updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2944: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Terminating an LRA MAY return the status of the LRA. > 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 6. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 15:09:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Oct 2017 15:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2945) Track SRAs that are started in the context of an LRA In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2945: -------------------------------------- Summary: Track SRAs that are started in the context of an LRA Key: JBTM-2945 URL: https://issues.jboss.org/browse/JBTM-2945 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later Often an LRA is built up from a number of individual actions performed by the participants enlisted with the LRA. These participants may use the ACID guarantees that an SRA provides in order to fulfil the requisite compensatory and completion actions when the LRA is terminated. To support this requirement when an SRA is started in the context of an LRA (either by annotating a method with both the @LRA and @SRA annotations or by starting an SRA via the client API when an LRA is already active) then the SRA will be automatically associated with the LRA. The following interface is provided for querying which LRAs and SRAs are associated with each other (in a one to many relationship): {code} public interface LRAToSRA { /** * return all the SRAs running in the context of the given LRA */ List getAssociatedSRAs(URL lraId}; /** * see if an LRA is associated with the give SRA */ URL getAssociatedLRA(URL sraId); } {code} Questions: - should @Compensate and @Complete block until all associated SRAs have finished - when an LRA is closed or cancelled should any active SRAs be automatically be committed or rolled back. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 15:32:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Oct 2017 15:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2946: -------------------------------------- Summary: LRA quickstart is not spec compliant Key: JBTM-2946 URL: https://issues.jboss.org/browse/JBTM-2946 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 15:42:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Oct 2017 15:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2946: ----------------------------------- Description: The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 was: The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > LRA quickstart is not spec compliant > ------------------------------------ > > Key: JBTM-2946 > URL: https://issues.jboss.org/browse/JBTM-2946 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). > The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 16:14:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Oct 2017 16:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #208 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA quickstart is not spec compliant > ------------------------------------ > > Key: JBTM-2946 > URL: https://issues.jboss.org/browse/JBTM-2946 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). > The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 17 05:45:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Oct 2017 05:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2947) LRA client API is still using the old spec In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2947: -------------------------------------- Summary: LRA client API is still using the old spec Key: JBTM-2947 URL: https://issues.jboss.org/browse/JBTM-2947 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The LRA end call in the client API is still expecting the response to contain are array of strings returned by each participant during the termination phase. The spec has since been updated and instead just the current status of the LRA is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 17 07:33:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Oct 2017 07:33:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2932. ---------------------------------- Resolution: Cannot Reproduce Bug This issue is no longer present so closing as cannot reproduce. > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 17 12:12:06 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Oct 2017 12:12:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2947) LRA client API is still using the old spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1232 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA client API is still using the old spec > ------------------------------------------ > > Key: JBTM-2947 > URL: https://issues.jboss.org/browse/JBTM-2947 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The LRA end call in the client API is still expecting the response to contain are array of strings returned by each participant during the termination phase. The spec has since been updated and instead just the current status of the LRA is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 17 16:47:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Oct 2017 16:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2947) LRA client API is still using the old spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2947: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA client API is still using the old spec > ------------------------------------------ > > Key: JBTM-2947 > URL: https://issues.jboss.org/browse/JBTM-2947 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The LRA end call in the client API is still expecting the response to contain are array of strings returned by each participant during the termination phase. The spec has since been updated and instead just the current status of the LRA is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 04:37:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 04:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2946: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA quickstart is not spec compliant > ------------------------------------ > > Key: JBTM-2946 > URL: https://issues.jboss.org/browse/JBTM-2946 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). > The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:02:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2943. ---------------------------------- Resolution: Duplicate Issue I missed this JIRA but fixed it in JBTM-2947 > Remove ability for participants to return business logic from their completion handlers > --------------------------------------------------------------------------------------- > > Key: JBTM-2943 > URL: https://issues.jboss.org/browse/JBTM-2943 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:04:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2941) Support JAX-RS unaware LRA participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2941: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Support JAX-RS unaware LRA participants > --------------------------------------- > > Key: JBTM-2941 > URL: https://issues.jboss.org/browse/JBTM-2941 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The LRA proposal includes a Java based compensation registration API to support those applications that cannot directly expose JAX-RS endpoints for compensation activities. This JIRA adds a reference implementation of that API. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:08:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2931) Allow CDI beans to perform transaction demarcation without being a participant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2931. ------------------------------------ Resolution: Done This was fixed as part of the fix for JBTM-2941 > Allow CDI beans to perform transaction demarcation without being a participant > ------------------------------------------------------------------------------ > > Key: JBTM-2931 > URL: https://issues.jboss.org/browse/JBTM-2931 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > > It would be useful for CDI beans to be marked @LRA without needing to declare participant too. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:10:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2930) Recovery is not supported by the LRA implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2930: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Recovery is not supported by the LRA implementation > --------------------------------------------------- > > Key: JBTM-2930 > URL: https://issues.jboss.org/browse/JBTM-2930 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The LRA implementation is missing recovery support. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:12:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Description: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2 was:Add LRA documentation. The current documentation resides in a private repository (https://github.com/jbosstm/microprofile-sandbox/blob/0009-LRA/proposals/0009-LRA/0009-LRA.md) and need to be in the narayana documentation repository. > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:13:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Priority: Major (was: Blocker) > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:14:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479152#comment-13479152 ] Michael Musgrove commented on JBTM-2929: ---------------------------------------- I have dropped the priority since the documentation is available via the eclipse MicroProfile sandbox. > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:22:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Description: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 was: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2 > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:23:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Description: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) was: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:23:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Description: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the sandbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) was: Add LRA documentation. The documentation is intended to be a MicroProfile specification and is available in the standbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the sandbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:28:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2929) Create LRA documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2929: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the sandbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668147f799967ab5923f47f739a3 (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:29:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2873) WildFly to GlassFish interop: check that recovery works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2873: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > WildFly to GlassFish interop: check that recovery works > ------------------------------------------------------- > > Key: JBTM-2873 > URL: https://issues.jboss.org/browse/JBTM-2873 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS > Affects Versions: 5.5.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Check interoperability between WildFly and GlassFish. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:30:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2833: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:30:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2831: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.later > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:31:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2740) Make the quickstart CI narayana.sh run script work on both clusters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2740. ---------------------------------- Resolution: Out of Date > Make the quickstart CI narayana.sh run script work on both clusters > ------------------------------------------------------------------- > > Key: JBTM-2740 > URL: https://issues.jboss.org/browse/JBTM-2740 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > > The script does not run on the NCL cluster most likely due to hard coded paths. > Fixing this will be useful because the current config hard codes which set of quickstarts to run (which is not maintainable as we add and remove quickstarts). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:32:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2700) Change quickstart poms to run tests and scripts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2700. ---------------------------------- Resolution: Out of Date > Change quickstart poms to run tests and scripts > ----------------------------------------------- > > Key: JBTM-2700 > URL: https://issues.jboss.org/browse/JBTM-2700 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Change quickstart poms to run tests and scripts -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 05:32:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 19 Oct 2017 05:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2664) Create a PR job to test SPI changes (against Narayana master) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2664: ----------------------------------- Priority: Optional (was: Major) > Create a PR job to test SPI changes (against Narayana master) > ------------------------------------------------------------- > > Key: JBTM-2664 > URL: https://issues.jboss.org/browse/JBTM-2664 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > > SPI changes should be tested against the current narayana master during github pull requests. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 10:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 10:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2880: -------------------------------- Fix Version/s: 5.next > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 10:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 10:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2880: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 10:51:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 10:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2939: -------------------------------- Fix Version/s: 5.next > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 10:51:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 10:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2939. --------------------------------- Resolution: Done > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 10:53:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 19 Oct 2017 10:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2948: ------------------------------------- Summary: NullPointer exception when beforeCompletion callback fails to prepare Key: JBTM-2948 URL: https://issues.jboss.org/browse/JBTM-2948 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core, XTS Affects Versions: 5.7.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. This situation could happen in case of trouble of WS-AT XTS of volatile participant. Let's look at the stack trace talk. First this is a failure of the beforeCompletion {code} TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false {code} as that failure happens we can see the later {{NullPointer}} {code} WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:06 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2947) LRA client API is still using the old spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2947. ------------------------------- > LRA client API is still using the old spec > ------------------------------------------ > > Key: JBTM-2947 > URL: https://issues.jboss.org/browse/JBTM-2947 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The LRA end call in the client API is still expecting the response to contain are array of strings returned by each participant during the termination phase. The spec has since been updated and instead just the current status of the LRA is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:06 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2946. ------------------------------- > LRA quickstart is not spec compliant > ------------------------------------ > > Key: JBTM-2946 > URL: https://issues.jboss.org/browse/JBTM-2946 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). > The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:06 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2941) Support JAX-RS unaware LRA participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2941. ------------------------------- > Support JAX-RS unaware LRA participants > --------------------------------------- > > Key: JBTM-2941 > URL: https://issues.jboss.org/browse/JBTM-2941 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The LRA proposal includes a Java based compensation registration API to support those applications that cannot directly expose JAX-RS endpoints for compensation activities. This JIRA adds a reference implementation of that API. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:06 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2944) LRA specification updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2944. ------------------------------- > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Terminating an LRA MAY return the status of the LRA. > 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 6. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:08 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2940) LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2940. ------------------------------- > LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2940 > URL: https://issues.jboss.org/browse/JBTM-2940 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The compensate and complete participant endpoints are allowed to return `202 Accepted` if they cannot complete the operation immediately in which case they should either return a status URL in the HTTP Location Header of the response or the resource class should contain a method annotated with @Status. > Recovery should then periodically probe the status and clean up once the status indicates that the participant has completed or compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:08 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2939. ------------------------------- > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.1.Final > > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:00:08 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:00:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2937) Do not recommend "X-" prefixed headers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2937. ------------------------------- > Do not recommend "X-" prefixed headers > -------------------------------------- > > Key: JBTM-2937 > URL: https://issues.jboss.org/browse/JBTM-2937 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > Quote from PR https://github.com/jbosstm/microprofile-sandbox/pull/3 raised by @nicolaferraro : > {quote} > A small change to the spec in order to use "Long-Running-Action" and "Short-Running-Action" headers instead of "X-lra" and "X-sra". > "X-" prefixed headers should be deprecated by RFC-6648 and RFC-7231. > They are not mandated by this spec, but they'll be used by microprofile rest services, so it's important for other technologies to use them if they want to build interoperable rest services. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2936. ------------------------------- > JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id > ------------------------------------------------------------------------------------ > > Key: JBTM-2936 > URL: https://issues.jboss.org/browse/JBTM-2936 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2935) Make LRA @Complete optional In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2935. ------------------------------- > Make LRA @Complete optional > --------------------------- > > Key: JBTM-2935 > URL: https://issues.jboss.org/browse/JBTM-2935 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > LRA compensators currently require both @Complete and @Compensate annotations to be present. The @Complete should be optional. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2934) LRA nested and parent coordinators should optimise calls when in a single VM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2934. ------------------------------- > LRA nested and parent coordinators should optimise calls when in a single VM > ---------------------------------------------------------------------------- > > Key: JBTM-2934 > URL: https://issues.jboss.org/browse/JBTM-2934 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Application Server Integration, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > LRA nested and parent coordinators use JAX-RS requests to driver the LRA protocol. When the two coordinators are in the same JVM direct jave method calls should be used. > The need for this enhancement is to support running on OpenShift. A secondary benefit is performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2931) Allow CDI beans to perform transaction demarcation without being a participant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2931. ------------------------------- > Allow CDI beans to perform transaction demarcation without being a participant > ------------------------------------------------------------------------------ > > Key: JBTM-2931 > URL: https://issues.jboss.org/browse/JBTM-2931 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > It would be useful for CDI beans to be marked @LRA without needing to declare participant too. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2880. ------------------------------- > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.1.Final > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2914) Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2914: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2914 > URL: https://issues.jboss.org/browse/JBTM-2914 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > Issue was discovered during https://issues.jboss.org/browse/JBEAP-11701 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2912: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Tom Jenkinson > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:01:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 11:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:11:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 19 Oct 2017 11:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1234 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 11:28:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 19 Oct 2017 11:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reopened JBTM-2880: ----------------------------------- I'm reopening this issue as there was provided only a partial fix - just few classes were handled. There is still quite a good bunch of them using the `printStatckTrace()`. > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.1.Final > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 19 14:38:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 19 Oct 2017 14:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2880: -------------------------------- Fix Version/s: 5.next > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.1.Final, 5.next > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 20 00:18:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Fri, 20 Oct 2017 00:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: Luis Barreiro created JBTM-2949: ----------------------------------- Summary: Remove synchronization from ThreadUtil.getThreadId Key: JBTM-2949 URL: https://issues.jboss.org/browse/JBTM-2949 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Luis Barreiro JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. There seems to be ways to remove this synchronization: # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 20 00:32:00 2017 From: issues at jboss.org (Anonymous (JIRA)) Date: Fri, 20 Oct 2017 00:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Luis Barreiro created pull request #1235 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 20 04:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 20 Oct 2017 04:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479746#comment-13479746 ] Tom Jenkinson commented on JBTM-2949: ------------------------------------- What about if a different JVM doesn't implement getId in that way? For example the IBM one may not? What would be the problem with using option 1? > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 20 12:25:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Fri, 20 Oct 2017 12:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480069#comment-13480069 ] Luis Barreiro commented on JBTM-2949: ------------------------------------- Looking at OpenJ9 code, it uses a counter as well. In the event that there is a JVM that does it differently, it won't be an issue unless IDs are reused fairly aggressively, which seems unlikely. The problem with option 1 is complexity, having to maintain a non-standard {{Map}}. Also, conceptually, assigning IDs to objects that already have one seems just wrong. > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 23 13:25:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 23 Oct 2017 13:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480727#comment-13480727 ] Tom Jenkinson commented on JBTM-2949: ------------------------------------- Did this shows as a hotspot in your debugger? I am re-running with the PERF profile to see if we see the benefit in our test suite: https://github.com/jbosstm/narayana/blob/206ff683a9923b8fce228c9d2602cce00c5a2c16/scripts/hudson/benchmark.sh#L79 > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 23 18:21:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 23 Oct 2017 18:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480795#comment-13480795 ] Ondra Chaloupka commented on JBTM-2948: --------------------------------------- After though investigation and test creation I consider this issue being only possible for XTS transactions. The base precondition is that {{reportHeuristics}} has to be true during {{BasicAction#doAbort}} call. That does not happen, what I can say, for standard arjuna core usage. > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 03:21:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 24 Oct 2017 03:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2948: ---------------------------------- Steps to Reproduce: The issue is described in some details under customer case 01952249. Reproducer added as testcase as part of the PR. was:Unfortunatelly I'm currently not able to reproduce the issue but it's described in some details under customer case 01952249. > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 04:50:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 24 Oct 2017 04:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481013#comment-13481013 ] Ondra Chaloupka commented on JBTM-2948: --------------------------------------- The WFLY-9455 issue was caught during investigation of this issue based on the same customer ticket. > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 06:31:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Oct 2017 06:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2932: ------------------------------------ The build only hangs on mac os > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 06:32:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Oct 2017 06:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2932: ----------------------------------- Attachment: dump.tar > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 06:34:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Oct 2017 06:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481092#comment-13481092 ] Michael Musgrove edited comment on JBTM-2932 at 10/24/17 6:33 AM: ------------------------------------------------------------------ The build only hangs on mac os I have attached the stacktrace of the two java threads (the file jvms shows the command lines) and the CI job output. was (Author: mmusgrov): The build only hangs on mac os > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 07:56:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 24 Oct 2017 07:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481133#comment-13481133 ] Tom Jenkinson commented on JBTM-2932: ------------------------------------- It is hanging because it fails to deploy: javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 08:09:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 24 Oct 2017 08:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481141#comment-13481141 ] Ondra Chaloupka commented on JBTM-2932: --------------------------------------- thanks, I need to investigate. some tests try to simulate deployment failures. it could be that deployment exception is the expected behavior. I'm not sure why the container (swarm) is not stopped as the next step > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 08:42:00 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Tue, 24 Oct 2017 08:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481179#comment-13481179 ] Luis Barreiro commented on JBTM-2949: ------------------------------------- It shows up not as a CPU but in latency, as threads need to wait to enter the synchronized block. The higher the number of concurrent threads, the more this effect is visible. > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 09:24:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 24 Oct 2017 09:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2948: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.7.2.Final Resolution: Done > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 24 10:24:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 24 Oct 2017 10:24:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481281#comment-13481281 ] Tom Jenkinson commented on JBTM-2949: ------------------------------------- I am wary about this due to the fact that someone would need to track the JDK source to see if the implementation ever changed (given the description of the API itself) > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 25 14:00:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 25 Oct 2017 14:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1238 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 25 14:01:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 25 Oct 2017 14:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481904#comment-13481904 ] Ondra Chaloupka commented on JBTM-2932: --------------------------------------- Adding timeout to not stuck whole testsuite and more logging. That could help, let's see. Note to myself: having embedded {{Swarm#main()}} is a classloading hell. Consider starting a new process to get the cleaner work (see https://github.com/zeroturnaround/zt-exec) > LRA Cdi REST integration test hang > ---------------------------------- > > Key: JBTM-2932 > URL: https://issues.jboss.org/browse/JBTM-2932 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Ondra Chaloupka > Attachments: dump.tar > > > The test is hanging. Swarm boots fine but it then just waits (forever): > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running io.narayana.lra.cdi.StartCdiCheckIT > Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO. > 2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > 2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > 2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > 2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > 2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > 2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > 2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final > CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final) > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: / > CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war") > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: / > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) > CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war") > CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting > CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message: > { > "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service > Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: > Exception 0 : > javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path > at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313) > at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125) > at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291) > at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197) > at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169) > at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159) > at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224) > at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383) > at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > "}, > "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping > CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms > CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ] > service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START] > service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START] > service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./] > service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService] > WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms > CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1 > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting > CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]] > CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting > CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem > CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server. > CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080 > CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 26 11:17:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 26 Oct 2017 11:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-989) Consider using a common code style throughout Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482374#comment-13482374 ] Ondra Chaloupka commented on JBTM-989: -------------------------------------- the LRA modules contains the checkstyle to have unified coding style based on the WFLY one: https://github.com/jbosstm/narayana/pull/1239 > Consider using a common code style throughout Narayana > ------------------------------------------------------ > > Key: JBTM-989 > URL: https://issues.jboss.org/browse/JBTM-989 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 4.17.0.M1/5.0.0.M1 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > > I think we should consider using a common code style throughout the TS project. The benefits of doing this are as follows: > # You can automate code formatting. This is a real productivity boost as you can type away, thinking about your code, rather than the style. When you hit save, or trigger it directly, the code is formatted. > ## This is not possible without a project wide code style as you too frequently re-format code that needs to stay in someone else's personal style. You can't commit this changed code as; a) it may annoy the "owner" and b) it results in a change that can't be diffed (every line may be changed). > # We get consistency over the whole project, making it easier to read code written by others. > # We have to do this anyway for code we maintain inside the JBossAS project as the project refuses to build if it doesn't adhere to their style. > Personally, I like the style I've used for the last 10 years. I find it harder to read code that is not in this style. Hence I can understand why people may object to changing their style. However, this is the very reason why a common style is beneficial. You can get used to a new style and once you do, the entire project will be styled in the way that you are used to. Providing the style is sensible, I would much rather use a style consistent across the projects I work on. I'm happy for that style to be different to my current style. > As I stated above JBossAS mandates a style at build time. I don't particularly like the style (braces should occupy their own line, IMO) but I'm happy to go with this one if it becomes the Narayana standard style. > I think we should also break the build for violations. This should prevent mistakes making their way into SVN. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Oct 27 11:22:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 27 Oct 2017 11:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482961#comment-13482961 ] Michael Musgrove commented on JBTM-2949: ---------------------------------------- I have taken a look back at older version of the code and we have already had four goes at implementing this (although we haven't tried Luis's approach): Fix 1: removeChildThread(Thread.currentThread().getName()); Fix 2 (JBOSSTS_4_2_2_GA): final String threadId = Integer.toHexString(System.identityHashCode(t)) ; Fix 3 (JBOSSTS_4_2_3_GA):_childThreads.put(ThreadUtil.getThreadId(t), t); Fix 4: the one that Tom did in the 5 stream. Clearly there is a history of getting this wrong and I would prefer not to try a new implementation without being able to quantify the benefit (I am not say there is no benefit but we need to see the numbers). > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 03:23:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 03:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2950: ------------------------------------- Summary: LRA logging is wrong in pointing to tsLogger and using System.out Key: JBTM-2950 URL: https://issues.jboss.org/browse/JBTM-2950 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. Up to that there should be more consistency and more informative for user. * There are hidden reasons of some failures in some places. * The error messages get from the URL queries are unclear in some cases, e.g. {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 03:28:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 03:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2951: ------------------------------------- Summary: Application using LRAClient starts with multiple warnings Key: JBTM-2951 URL: https://issues.jboss.org/browse/JBTM-2951 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor When starting an application using {{LRAClient}} I get several warnings during startup {code} 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 03:32:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 03:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483199#comment-13483199 ] Ondra Chaloupka commented on JBTM-2951: --------------------------------------- these warnings are caused by registration of the REST provider - once via {{@Provider}} annotation, second via descriptor {{javax.ws.rs.ext.Providers}}. Only one way should be enough. > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 04:24:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 04:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1240 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 18:26:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 18:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2952: ------------------------------------- Summary: LRA rest cdi checker should not demand @Status Key: JBTM-2952 URL: https://issues.jboss.org/browse/JBTM-2952 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 18:35:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 18:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1242 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 30 18:35:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 30 Oct 2017 18:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1241 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Oct 31 07:30:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 31 Oct 2017 07:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2953) Support asynchronous LRA participants In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2953: -------------------------------------- Summary: Support asynchronous LRA participants Key: JBTM-2953 URL: https://issues.jboss.org/browse/JBTM-2953 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later When an asynchronous jax-rs method is annotated as an LRA (ie has the @LRA annotation), for example: {code} @GET @LRA public void someAction(@Suspended AsyncResponse ar) throws InterruptedException { ... } {code} the LRA filter does not respect the asynchronous nature of the call. What needs to happen is for LRA jax-rs filter (ServerLRAFilter.java) to issue an asynchronous join request to the coordinator and to link that future to the jax-rs resource AsyncResponse callback. And since the ServerLRAFilter cannot immediately supply the LRAId to the resource method we also need a method on LRAClient analogous to getCurrent but which returns a Future for the lra id. -- This message was sent by Atlassian JIRA (v7.5.0#75005)