From issues at jboss.org  Wed May  1 09:58:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 1 May 2019 09:58:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3142) Upgrade to the latest
 parent pom (org.jboss:jboss-parent:35)
In-Reply-To: <JIRA.12805175.1556719043000@Atlassian.JIRA>
References: <JIRA.12805175.1556719043000@Atlassian.JIRA>
	<JIRA.12805175.1556719043629@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12805175.1556719043000.100375.1556719080305@Atlassian.JIRA>

Michael Musgrove created JBTM-3142:
--------------------------------------

             Summary: Upgrade to the latest parent pom (org.jboss:jboss-parent:35)
                 Key: JBTM-3142
                 URL: https://issues.jboss.org/browse/JBTM-3142
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Build System
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


Upgrade our top level pom parent to use the lates version of jboss-parent ((org.jboss:jboss-parent:35)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May  1 10:09:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 1 May 2019 10:09:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3142) Upgrade to the latest
 parent pom (org.jboss:jboss-parent:35)
In-Reply-To: <JIRA.12805175.1556719044000@Atlassian.JIRA>
References: <JIRA.12805175.1556719044000@Atlassian.JIRA>
	<JIRA.12805175.1556719044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12805175.1556719044000.100414.1556719740121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1447 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Upgrade to the latest parent pom (org.jboss:jboss-parent:35)
> ------------------------------------------------------------
>
>                 Key: JBTM-3142
>                 URL: https://issues.jboss.org/browse/JBTM-3142
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> Upgrade our top level pom parent to use the lates version of jboss-parent ((org.jboss:jboss-parent:35)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu May  2 16:15:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Thu, 2 May 2019 16:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3143) Enable ArjunaJTS/jts
 Narayana quickstart to be run as automated testcase
In-Reply-To: <JIRA.12805438.1556828059000@Atlassian.JIRA>
References: <JIRA.12805438.1556828059000@Atlassian.JIRA>
	<JIRA.12805438.1556828059356@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12805438.1556828059000.109854.1556828100085@Atlassian.JIRA>

Ondrej Chaloupka created JBTM-3143:
--------------------------------------

             Summary: Enable ArjunaJTS/jts Narayana quickstart to be run as automated testcase
                 Key: JBTM-3143
                 URL: https://issues.jboss.org/browse/JBTM-3143
             Project: JBoss Transaction Manager
          Issue Type: Enhancement
          Components: Testing
            Reporter: Ondrej Chaloupka
            Assignee: Ondrej Chaloupka


ArjunaJTS/jts is nor run as is not defined as {{<module>}} under {{ArjunaJTS]} quickstart folder.
When activated there is no active test to be run. Renaming {{CallJTSCMTBean}} to {{CallJTSCMTTest}} makes the test to be launched but as the test does not define a way to deploy components ({{1}}, {{2}}) to WFLY server the test fails. Arquillian deployment is probably needed to get automatic WFLY startup and deploy.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 14 03:24:01 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 14 May 2019 03:24:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3144) LRA TCK Test Failure
In-Reply-To: <JIRA.12806907.1557818619000@Atlassian.JIRA>
References: <JIRA.12806907.1557818619000@Atlassian.JIRA>
	<JIRA.12806907.1557818619471@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12806907.1557818619000.39081.1557818641462@Atlassian.JIRA>

Michael Musgrove created JBTM-3144:
--------------------------------------

             Summary: LRA TCK Test Failure
                 Key: JBTM-3144
                 URL: https://issues.jboss.org/browse/JBTM-3144
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 14 06:29:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 14 May 2019 06:29:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3144) LRA TCK Test Failure
In-Reply-To: <JIRA.12806907.1557818619000@Atlassian.JIRA>
References: <JIRA.12806907.1557818619000@Atlassian.JIRA>
	<JIRA.12806907.1557818619000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12806907.1557818619000.40555.1557829740105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-3144:
-----------------------------------
    Description: 
The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.

TckTests.timeLimit has also been seen to fail (probably for the same reason)

  was:The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.



> LRA TCK Test Failure
> --------------------
>
>                 Key: JBTM-3144
>                 URL: https://issues.jboss.org/browse/JBTM-3144
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.
> TckTests.timeLimit has also been seen to fail (probably for the same reason)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 15 03:23:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 15 May 2019 03:23:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3144) LRA TCK Test Failure
In-Reply-To: <JIRA.12806907.1557818619000@Atlassian.JIRA>
References: <JIRA.12806907.1557818619000@Atlassian.JIRA>
	<JIRA.12806907.1557818619000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12806907.1557818619000.46691.1557904980097@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1449 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> LRA TCK Test Failure
> --------------------
>
>                 Key: JBTM-3144
>                 URL: https://issues.jboss.org/browse/JBTM-3144
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.
> TckTests.timeLimit has also been seen to fail (probably for the same reason)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 15 05:17:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 15 May 2019 05:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3144) LRA TCK Test Failure
In-Reply-To: <JIRA.12806907.1557818619000@Atlassian.JIRA>
References: <JIRA.12806907.1557818619000@Atlassian.JIRA>
	<JIRA.12806907.1557818619000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12806907.1557818619000.47492.1557911820363@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-3144:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


The TCK ran to completion against the PR so assuming the fix is good

> LRA TCK Test Failure
> --------------------
>
>                 Key: JBTM-3144
>                 URL: https://issues.jboss.org/browse/JBTM-3144
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> The TCK test TckTests.acceptCancelTest is failing consistently. The test needs to wait for a recovery pass but the upstream project (Microprofile LRA) where the test is defined was recently changed to use timeouts and I suspect the test is not waiting long enough for the recovery to occur.
> TckTests.timeLimit has also been seen to fail (probably for the same reason)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 15 08:48:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 15 May 2019 08:48:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3136) Verify that Narayaya
 projects download dependencies via HTTPS
In-Reply-To: <JIRA.12801927.1554971706000@Atlassian.JIRA>
References: <JIRA.12801927.1554971706000@Atlassian.JIRA>
	<JIRA.12801927.1554971706000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12801927.1554971706000.49195.1557924480246@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-3136:
-----------------------------------
    Security:     (was: Security Issue)


> Verify that Narayaya projects download dependencies via HTTPS
> -------------------------------------------------------------
>
>                 Key: JBTM-3136
>                 URL: https://issues.jboss.org/browse/JBTM-3136
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> Verify and fix if necessary that the following projects download dependencies using HTTPS:
> https://github.com/jboss/jboss-transaction-api_spec
> https://github.com/jbosstm/jboss-transaction-spi
> https://github.com/jbosstm/narayana
> https://github.com/jbosstm/quickstart



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Mon May 20 04:37:00 2019
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Mon, 20 May 2019 04:37:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3087) Ensure the LRA
 implementation is up to date
In-Reply-To: <JIRA.12783379.1544523365000@Atlassian.JIRA>
References: <JIRA.12783379.1544523365000@Atlassian.JIRA>
	<JIRA.12783379.1544523365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12783379.1544523365000.2132.1558341420744@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735325#comment-13735325 ] 

Martin Stefanko commented on JBTM-3087:
---------------------------------------

Next PR - https://github.com/jbosstm/narayana/pull/1450. Versions:


{code:xml}
<version.microprofile.lra.api>1.0-20190519.061148-384</version.microprofile.lra.api>
<version.microprofile.lra.tck>1.0-20190519.061150-384</version.microprofile.lra.tck>
{code}


> Ensure the LRA implementation is up to date
> -------------------------------------------
>
>                 Key: JBTM-3087
>                 URL: https://issues.jboss.org/browse/JBTM-3087
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 21 04:20:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 21 May 2019 04:20:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3145) LRA TCK test failure on
	JDK11
In-Reply-To: <JIRA.12808075.1558426756000@Atlassian.JIRA>
References: <JIRA.12808075.1558426756000@Atlassian.JIRA>
	<JIRA.12808075.1558426756791@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12808075.1558426756000.10567.1558426800929@Atlassian.JIRA>

Michael Musgrove created JBTM-3145:
--------------------------------------

             Summary: LRA TCK test failure on JDK11
                 Key: JBTM-3145
                 URL: https://issues.jboss.org/browse/JBTM-3145
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/416/PROFILE=LRA,jdk=jdk11.latest,label=linux/



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 24 02:15:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Fri, 24 May 2019 02:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2924) Add some more trace
 statement to make it clear which connection modifier is in use for the
 TransactionalDriver
In-Reply-To: <JIRA.12709810.1504285271000@Atlassian.JIRA>
References: <JIRA.12709810.1504285271000@Atlassian.JIRA>
	<JIRA.12709810.1504285271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709810.1504285271000.13857.1558678500114@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-2924:
-----------------------------------
    Issue Type: Enhancement  (was: Component Upgrade)


> Add some more trace statement to make it clear which connection modifier is in use for the TransactionalDriver
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2924
>                 URL: https://issues.jboss.org/browse/JBTM-2924
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transactional Driver
>            Reporter: Thomas Jenkinson
>            Assignee: Thomas Jenkinson
>            Priority: Minor
>
> It is not clear which one is used and whether the override is in effect



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 24 02:15:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Fri, 24 May 2019 02:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2924) Add some more trace
 statement to make it clear which connection modifier is in use for the
 TransactionalDriver
In-Reply-To: <JIRA.12709810.1504285271000@Atlassian.JIRA>
References: <JIRA.12709810.1504285271000@Atlassian.JIRA>
	<JIRA.12709810.1504285271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709810.1504285271000.13859.1558678500392@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-2924:
-----------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/jbosstm/narayana/pull/1206


> Add some more trace statement to make it clear which connection modifier is in use for the TransactionalDriver
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2924
>                 URL: https://issues.jboss.org/browse/JBTM-2924
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transactional Driver
>            Reporter: Thomas Jenkinson
>            Assignee: Thomas Jenkinson
>            Priority: Minor
>
> It is not clear which one is used and whether the override is in effect



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 24 02:17:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Fri, 24 May 2019 02:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2924) Add some more trace
 statement to make it clear which connection modifier is in use for the
 TransactionalDriver
In-Reply-To: <JIRA.12709810.1504285271000@Atlassian.JIRA>
References: <JIRA.12709810.1504285271000@Atlassian.JIRA>
	<JIRA.12709810.1504285271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709810.1504285271000.13871.1558678620104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-2924:
-----------------------------------
           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 5.7.0.Final
       Resolution: Done


I'm setting the resolution to `Done` as there is a merge PR which seems to address the issue.

> Add some more trace statement to make it clear which connection modifier is in use for the TransactionalDriver
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2924
>                 URL: https://issues.jboss.org/browse/JBTM-2924
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transactional Driver
>            Reporter: Thomas Jenkinson
>            Assignee: Thomas Jenkinson
>            Priority: Minor
>             Fix For: 5.7.0.Final
>
>
> It is not clear which one is used and whether the override is in effect



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 24 02:17:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Fri, 24 May 2019 02:17:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2924) Add some more trace
 statement to make it clear which connection modifier is in use for the
 TransactionalDriver
In-Reply-To: <JIRA.12709810.1504285271000@Atlassian.JIRA>
References: <JIRA.12709810.1504285271000@Atlassian.JIRA>
	<JIRA.12709810.1504285271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709810.1504285271000.13873.1558678620143@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka closed JBTM-2924.
----------------------------------


> Add some more trace statement to make it clear which connection modifier is in use for the TransactionalDriver
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-2924
>                 URL: https://issues.jboss.org/browse/JBTM-2924
>             Project: JBoss Transaction Manager
>          Issue Type: Enhancement
>          Components: Transactional Driver
>            Reporter: Thomas Jenkinson
>            Assignee: Thomas Jenkinson
>            Priority: Minor
>             Fix For: 5.7.0.Final
>
>
> It is not clear which one is used and whether the override is in effect



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 03:56:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 28 May 2019 03:56:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3146) Better support for Quarkus
In-Reply-To: <JIRA.12809331.1559030158000@Atlassian.JIRA>
References: <JIRA.12809331.1559030158000@Atlassian.JIRA>
	<JIRA.12809331.1559030158543@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809331.1559030158000.28362.1559030160077@Atlassian.JIRA>

Michael Musgrove created JBTM-3146:
--------------------------------------

             Summary: Better support for Quarkus
                 Key: JBTM-3146
                 URL: https://issues.jboss.org/browse/JBTM-3146
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Common
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


To facilitate use of Narayana with containers such as Quarkus we want to minimise things like XML parsing and java archive parsing. The two main enhancements that would be useful in this respect are:

 * to inject build information into a java class (via the org.jboss.maven.plugins:maven-injection-plugin plugin);
 * to avoid the need for runtime parsing of XML properties it would be useful to allow the properties factory delegate to be supplied externally



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 04:03:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 28 May 2019 04:03:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3146) Better support for Quarkus
In-Reply-To: <JIRA.12809331.1559030159000@Atlassian.JIRA>
References: <JIRA.12809331.1559030159000@Atlassian.JIRA>
	<JIRA.12809331.1559030159000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809331.1559030159000.28413.1559030580136@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1451 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Better support for Quarkus
> --------------------------
>
>                 Key: JBTM-3146
>                 URL: https://issues.jboss.org/browse/JBTM-3146
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> To facilitate use of Narayana with containers such as Quarkus we want to minimise things like XML parsing and java archive parsing. The two main enhancements that would be useful in this respect are:
>  * to inject build information into a java class (via the org.jboss.maven.plugins:maven-injection-plugin plugin);
>  * to avoid the need for runtime parsing of XML properties it would be useful to allow the properties factory delegate to be supplied externally



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 04:47:01 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 04:47:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3147) WS-AT participant which
 timeouts on prepare is not aborted but put to heuristic state
In-Reply-To: <JIRA.12809345.1559033190000@Atlassian.JIRA>
References: <JIRA.12809345.1559033190000@Atlassian.JIRA>
	<JIRA.12809345.1559033190014@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809345.1559033190000.28866.1559033221467@Atlassian.JIRA>

Ondrej Chaloupka created JBTM-3147:
--------------------------------------

             Summary: WS-AT participant which timeouts on prepare is not aborted but put to heuristic state
                 Key: JBTM-3147
                 URL: https://issues.jboss.org/browse/JBTM-3147
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: XTS
            Reporter: Ondrej Chaloupka
            Assignee: Ondrej Chaloupka
             Fix For: 5.9.5.Final


When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 05:14:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 05:14:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3147) WS-AT participant which
 timeouts on prepare is not aborted but put to heuristic state
In-Reply-To: <JIRA.12809345.1559033190000@Atlassian.JIRA>
References: <JIRA.12809345.1559033190000@Atlassian.JIRA>
	<JIRA.12809345.1559033190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809345.1559033190000.29165.1559034840244@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3147:
-----------------------------------
    Description: 
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}

The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232

  was:
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}



> WS-AT participant which timeouts on prepare is not aborted but put to heuristic state
> -------------------------------------------------------------------------------------
>
>                 Key: JBTM-3147
>                 URL: https://issues.jboss.org/browse/JBTM-3147
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>             Fix For: 5.9.5.Final
>
>
> When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.
> This behaviour is confirmed by comments in the source code and tests expect such behaviour.
> Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
> https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362
> {quote}
> // if prepare timed out then we return error so it goes back on the
> // prepare list and is rolled back
> {quote}
> The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
> See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 05:14:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 05:14:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3147) WS-AT participant which
 timeouts on prepare is not aborted and cancel is not retried but both are
 put to heuristic state
In-Reply-To: <JIRA.12809345.1559033190000@Atlassian.JIRA>
References: <JIRA.12809345.1559033190000@Atlassian.JIRA>
	<JIRA.12809345.1559033190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809345.1559033190000.29170.1559034840396@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3147:
-----------------------------------
    Summary: WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state  (was: WS-AT participant which timeouts on prepare is not aborted but put to heuristic state)


> WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-3147
>                 URL: https://issues.jboss.org/browse/JBTM-3147
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>             Fix For: 5.9.5.Final
>
>
> When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.
> This behaviour is confirmed by comments in the source code and tests expect such behaviour.
> Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
> https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362
> {quote}
> // if prepare timed out then we return error so it goes back on the
> // prepare list and is rolled back
> {quote}
> The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
> See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 05:15:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 05:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3147) WS-AT participant which
 timeouts on prepare is not aborted and cancel is not retried but both are
 put to heuristic state
In-Reply-To: <JIRA.12809345.1559033190000@Atlassian.JIRA>
References: <JIRA.12809345.1559033190000@Atlassian.JIRA>
	<JIRA.12809345.1559033190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809345.1559033190000.29175.1559034900400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3147:
-----------------------------------
    Description: 
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}

The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants
/DurableTwoPhaseCommitParticipant.java#L232

{quote}
// log an error here -- if the participant is dead it will retry anyway
{quote}

  was:
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}

The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232



> WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-3147
>                 URL: https://issues.jboss.org/browse/JBTM-3147
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>             Fix For: 5.9.5.Final
>
>
> When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.
> This behaviour is confirmed by comments in the source code and tests expect such behaviour.
> Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
> https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362
> {quote}
> // if prepare timed out then we return error so it goes back on the
> // prepare list and is rolled back
> {quote}
> The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
> See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants
> /DurableTwoPhaseCommitParticipant.java#L232
> {quote}
> // log an error here -- if the participant is dead it will retry anyway
> {quote}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 05:15:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 05:15:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3147) WS-AT participant which
 timeouts on prepare is not aborted and cancel is not retried but both are
 put to heuristic state
In-Reply-To: <JIRA.12809345.1559033190000@Atlassian.JIRA>
References: <JIRA.12809345.1559033190000@Atlassian.JIRA>
	<JIRA.12809345.1559033190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809345.1559033190000.29177.1559034900499@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3147:
-----------------------------------
    Description: 
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}

The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232

{quote}
// log an error here -- if the participant is dead it will retry anyway
{quote}

  was:
When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.

This behaviour is confirmed by comments in the source code and tests expect such behaviour.

Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362

{quote}
// if prepare timed out then we return error so it goes back on the
// prepare list and is rolled back
{quote}

The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants
/DurableTwoPhaseCommitParticipant.java#L232

{quote}
// log an error here -- if the participant is dead it will retry anyway
{quote}



> WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-3147
>                 URL: https://issues.jboss.org/browse/JBTM-3147
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: XTS
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>             Fix For: 5.9.5.Final
>
>
> When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted.
> This behaviour is confirmed by comments in the source code and tests expect such behaviour.
> Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks
> https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java#L362
> {quote}
> // if prepare timed out then we return error so it goes back on the
> // prepare list and is rolled back
> {quote}
> The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned.
> See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java#L232
> {quote}
> // log an error here -- if the participant is dead it will retry anyway
> {quote}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 08:47:01 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Tue, 28 May 2019 08:47:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3146) Better support for Quarkus
In-Reply-To: <JIRA.12809331.1559030159000@Atlassian.JIRA>
References: <JIRA.12809331.1559030159000@Atlassian.JIRA>
	<JIRA.12809331.1559030159000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809331.1559030159000.30967.1559047621581@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Musgrove updated JBTM-3146:
-----------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


The reviewer left an interesting note on the PR which requires following up:

{quote}
related: Whilst JBTM-3146 is clearly a tactical fix for Quarkus, is there a wider discussion of how default properties will work going forwards? With injection available, does it make sense to do away with the default properties file in a build in favor of injecting those defaults directly to the beans at build time? The stumbling block may be beans that exist in one module/jar but get their value from another (e.g. core configured by jta/jts) so it may lead to a messy hybrid approach that still needs files for some properties.
{quote}

> Better support for Quarkus
> --------------------------
>
>                 Key: JBTM-3146
>                 URL: https://issues.jboss.org/browse/JBTM-3146
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> To facilitate use of Narayana with containers such as Quarkus we want to minimise things like XML parsing and java archive parsing. The two main enhancements that would be useful in this respect are:
>  * to inject build information into a java class (via the org.jboss.maven.plugins:maven-injection-plugin plugin);
>  * to avoid the need for runtime parsing of XML properties it would be useful to allow the properties factory delegate to be supplied externally



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 11:29:01 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 11:29:01 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3148) Remote JTA EJB
 tramsaction context propagation with fails to correctly run 1PC
In-Reply-To: <JIRA.12809519.1559057301000@Atlassian.JIRA>
References: <JIRA.12809519.1559057301000@Atlassian.JIRA>
	<JIRA.12809519.1559057301351@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809519.1559057301000.33432.1559057341188@Atlassian.JIRA>

Ondrej Chaloupka created JBTM-3148:
--------------------------------------

             Summary: Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC
                 Key: JBTM-3148
                 URL: https://issues.jboss.org/browse/JBTM-3148
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: JTA
    Affects Versions: 5.9.5.Final
            Reporter: Ondrej Chaloupka
            Assignee: Ondrej Chaloupka


Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.

Consider:
. first server calls a second server
. the first server uses as the resource only the remote call to the second server
. transaction context is propagated and used at the second server
. the second server makes some changes in database and sends data to JMS broker (2 XAResources)
. 1PC is used to run commit on the only XAResource at the first server which is EJB remote XAResource
. the second server is called with one phase commit
. the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
. prepare on database resource and JMS resource is run
. commit runs on the database resource, then...
. JVM crashes before JMS broker is committed
. (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)

In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.

The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png

Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443

In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.

One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.




--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 11:30:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 11:30:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3148) Remote JTA EJB
 tramsaction context propagation with fails to correctly run 1PC
In-Reply-To: <JIRA.12809519.1559057301000@Atlassian.JIRA>
References: <JIRA.12809519.1559057301000@Atlassian.JIRA>
	<JIRA.12809519.1559057301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809519.1559057301000.33446.1559057400639@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3148:
-----------------------------------
    Description: 
Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.

Consider:

# first server calls a second server
# the first server uses as the resource only the remote call to the second server
# transaction context is propagated and used at the second server
# the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
# 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
# the second server is called with one phase commit
# the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
# prepare on database resource and JMS resource is run
# commit runs on the database resource, then...
# JVM crashes before JMS broker is committed
# (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)

In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.

The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png

Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443

In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.

One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.


  was:
Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.

Consider:
. first server calls a second server
. the first server uses as the resource only the remote call to the second server
. transaction context is propagated and used at the second server
. the second server makes some changes in database and sends data to JMS broker (2 XAResources)
. 1PC is used to run commit on the only XAResource at the first server which is EJB remote XAResource
. the second server is called with one phase commit
. the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
. prepare on database resource and JMS resource is run
. commit runs on the database resource, then...
. JVM crashes before JMS broker is committed
. (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)

In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.

The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png

Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443

In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.

One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.




> Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-3148
>                 URL: https://issues.jboss.org/browse/JBTM-3148
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>    Affects Versions: 5.9.5.Final
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 11:41:03 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 11:41:03 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3148) Remote JTA EJB
 tramsaction context propagation with fails to correctly run 1PC
In-Reply-To: <JIRA.12809519.1559057301000@Atlassian.JIRA>
References: <JIRA.12809519.1559057301000@Atlassian.JIRA>
	<JIRA.12809519.1559057301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809519.1559057301000.33580.1559058063102@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3148:
-----------------------------------
    Forum Reference: https://developer.jboss.org/thread/279243


> Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-3148
>                 URL: https://issues.jboss.org/browse/JBTM-3148
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>    Affects Versions: 5.9.5.Final
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 11:41:06 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 11:41:06 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3148) Remote JTA EJB
 tramsaction context propagation with fails to correctly run 1PC
In-Reply-To: <JIRA.12809519.1559057301000@Atlassian.JIRA>
References: <JIRA.12809519.1559057301000@Atlassian.JIRA>
	<JIRA.12809519.1559057301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809519.1559057301000.33693.1559058066167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Chaloupka updated JBTM-3148:
-----------------------------------
    Forum Reference: https://developer.jboss.org/message/989167#989167  (was: https://developer.jboss.org/thread/279243)


> Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-3148
>                 URL: https://issues.jboss.org/browse/JBTM-3148
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>    Affects Versions: 5.9.5.Final
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Tue May 28 12:05:00 2019
From: issues at jboss.org (Ondrej Chaloupka (Jira))
Date: Tue, 28 May 2019 12:05:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3148) Remote JTA EJB
 tramsaction context propagation with fails to correctly run 1PC
In-Reply-To: <JIRA.12809519.1559057301000@Atlassian.JIRA>
References: <JIRA.12809519.1559057301000@Atlassian.JIRA>
	<JIRA.12809519.1559057301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809519.1559057301000.34098.1559059500390@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Ondrej Chaloupka created pull request #1452 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC
> ------------------------------------------------------------------------------
>
>                 Key: JBTM-3148
>                 URL: https://issues.jboss.org/browse/JBTM-3148
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: JTA
>    Affects Versions: 5.9.5.Final
>            Reporter: Ondrej Chaloupka
>            Assignee: Ondrej Chaloupka
>            Priority: Major
>
> Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit  {{EJB remote XAResource.commit}} we can't define outcome.
> Consider:
> # first server calls a second server
> # the first server uses as the resource only the remote call to the second server
> # transaction context is propagated and used at the second server
> # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s)
> # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}}
> # the second server is called with one phase commit
> # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources
> # prepare on database resource and JMS resource is run
> # commit runs on the database resource, then...
> # JVM crashes before JMS broker is committed
> # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown)
> In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit.
> The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation
> https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301/drawio+diagram.png
> Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443
> In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten.
> That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit.
> One option is to  force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443).
> The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 29 03:01:00 2019
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Wed, 29 May 2019 03:01:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259060@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.37693.1559113260229@Atlassian.JIRA>

Martin Stefanko created JBTM-3149:
-------------------------------------

             Summary: LRA proxy test module failing with maven >3.6.0
                 Key: JBTM-3149
                 URL: https://issues.jboss.org/browse/JBTM-3149
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: LRA
    Affects Versions: 5.9.5.Final
            Reporter: Martin Stefanko
            Assignee: Martin Stefanko


Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with

{code:java}
[ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
[ERROR] -----------------------------------------------------
[ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
[ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
[ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
[ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
[ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
[ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
[ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
[ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
[ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
[ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
[ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
[ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
[ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
[ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
[ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
[ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
[ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
[ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
[ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
[ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
[ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
[ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
[ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
[ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
[ERROR] Number of foreign imports: 1

{code}


{{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
{{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
{{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS




--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 29 03:14:00 2019
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Wed, 29 May 2019 03:14:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >=3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.37753.1559114040262@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stefanko updated JBTM-3149:
----------------------------------
    Summary: LRA proxy test module failing with maven >=3.6.0  (was: LRA proxy test module failing with maven >3.6.0)


> LRA proxy test module failing with maven >=3.6.0
> ------------------------------------------------
>
>                 Key: JBTM-3149
>                 URL: https://issues.jboss.org/browse/JBTM-3149
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>
> Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with
> {code:java}
> [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
> [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
> [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
> [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
> [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
> [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
> [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
> [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
> [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
> [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
> [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
> [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
> [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
> [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
> [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
> [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
> [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
> [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
> [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
> [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
> [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
> [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
> [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] Number of foreign imports: 1
> {code}
> {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 29 03:16:00 2019
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Wed, 29 May 2019 03:16:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >=3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.37770.1559114160070@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on JBTM-3149 started by Martin Stefanko.
---------------------------------------------
> LRA proxy test module failing with maven >=3.6.0
> ------------------------------------------------
>
>                 Key: JBTM-3149
>                 URL: https://issues.jboss.org/browse/JBTM-3149
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>
> Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with
> {code:java}
> [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
> [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
> [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
> [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
> [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
> [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
> [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
> [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
> [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
> [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
> [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
> [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
> [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
> [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
> [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
> [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
> [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
> [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
> [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
> [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
> [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
> [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
> [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] Number of foreign imports: 1
> {code}
> {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Wed May 29 04:20:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Wed, 29 May 2019 04:20:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3150) Upgrade the version of
 maven that we use to build with
In-Reply-To: <JIRA.12809675.1559117943000@Atlassian.JIRA>
References: <JIRA.12809675.1559117943000@Atlassian.JIRA>
	<JIRA.12809675.1559117943535@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809675.1559117943000.38317.1559118000142@Atlassian.JIRA>

Michael Musgrove created JBTM-3150:
--------------------------------------

             Summary: Upgrade the version of maven that we use to build with
                 Key: JBTM-3150
                 URL: https://issues.jboss.org/browse/JBTM-3150
             Project: JBoss Transaction Manager
          Issue Type: Task
          Components: Build System
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


Narayana builds with version 3.3.9 of maven. This version is quite old and does not work with containers such as thorntail and quarkus. This JIRA is to upgrade our build to use version 3.6.1



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu May 30 02:45:00 2019
From: issues at jboss.org (Martin Stefanko (Jira))
Date: Thu, 30 May 2019 02:45:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >=3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.45988.1559198700152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740338#comment-13740338 ] 

Martin Stefanko commented on JBTM-3149:
---------------------------------------

wildfly-swarm-plugin is quite outdated. I would like to propose to update all LRA services to use thorntail. [~mmusgrov] WDYT?

> LRA proxy test module failing with maven >=3.6.0
> ------------------------------------------------
>
>                 Key: JBTM-3149
>                 URL: https://issues.jboss.org/browse/JBTM-3149
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>
> Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with
> {code:java}
> [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
> [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
> [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
> [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
> [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
> [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
> [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
> [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
> [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
> [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
> [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
> [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
> [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
> [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
> [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
> [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
> [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
> [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
> [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
> [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
> [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
> [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
> [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] Number of foreign imports: 1
> {code}
> {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu May 30 11:47:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 30 May 2019 11:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >=3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.50813.1559231220262@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740635#comment-13740635 ] 

Michael Musgrove commented on JBTM-3149:
----------------------------------------

Yes we just need to upgrade the maven version and do the migration

> mvn io.thorntail:thorntail-maven-plugin:2.3.0.Final:migrate-from-wildfly-swarm

> LRA proxy test module failing with maven >=3.6.0
> ------------------------------------------------
>
>                 Key: JBTM-3149
>                 URL: https://issues.jboss.org/browse/JBTM-3149
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>
> Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with
> {code:java}
> [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
> [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
> [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
> [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
> [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
> [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
> [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
> [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
> [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
> [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
> [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
> [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
> [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
> [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
> [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
> [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
> [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
> [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
> [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
> [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
> [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
> [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
> [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] Number of foreign imports: 1
> {code}
> {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Thu May 30 11:47:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Thu, 30 May 2019 11:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3149) LRA proxy test module
 failing with maven >=3.6.0
In-Reply-To: <JIRA.12809670.1559113259000@Atlassian.JIRA>
References: <JIRA.12809670.1559113259000@Atlassian.JIRA>
	<JIRA.12809670.1559113259000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809670.1559113259000.50819.1559231220396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13740635#comment-13740635 ] 

Michael Musgrove edited comment on JBTM-3149 at 5/30/19 11:46 AM:
------------------------------------------------------------------

Yes we just need to upgrade the maven version and do the migration

> mvn io.thorntail:thorntail-maven-plugin:2.3.0.Final:migrate-from-wildfly-swarm

I was planning on doing it this week sometime


was (Author: mmusgrov):
Yes we just need to upgrade the maven version and do the migration

> mvn io.thorntail:thorntail-maven-plugin:2.3.0.Final:migrate-from-wildfly-swarm

> LRA proxy test module failing with maven >=3.6.0
> ------------------------------------------------
>
>                 Key: JBTM-3149
>                 URL: https://issues.jboss.org/browse/JBTM-3149
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.9.5.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>
> Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with
> {code:java}
> [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar
> [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar
> [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar
> [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar
> [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar
> [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar
> [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar
> [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar
> [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar
> [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar
> [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar
> [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar
> [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar
> [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar
> [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar
> [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar
> [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar
> [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar
> [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar
> [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar
> [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar
> [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar
> [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] Number of foreign imports: 1
> {code}
> {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR
> {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 31 05:47:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Fri, 31 May 2019 05:47:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3150) Upgrade the version of
 maven that we use to build with
In-Reply-To: <JIRA.12809675.1559117944000@Atlassian.JIRA>
References: <JIRA.12809675.1559117944000@Atlassian.JIRA>
	<JIRA.12809675.1559117944000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12809675.1559117944000.53436.1559296020209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBTM-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Issue was automatically transitioned when Michael Musgrove created pull request #1453 in GitHub
-----------------------------------------------------------------------------------------------
    Status: Pull Request Sent  (was: Open)


> Upgrade the version of maven that we use to build with
> ------------------------------------------------------
>
>                 Key: JBTM-3150
>                 URL: https://issues.jboss.org/browse/JBTM-3150
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 5.9.5.Final
>            Reporter: Michael Musgrove
>            Assignee: Michael Musgrove
>            Priority: Major
>             Fix For: 5.next
>
>
> Narayana builds with version 3.3.9 of maven. This version is quite old and does not work with containers such as thorntail and quarkus. This JIRA is to upgrade our build to use version 3.6.1



--
This message was sent by Atlassian Jira
(v7.12.1#712002)

From issues at jboss.org  Fri May 31 14:09:00 2019
From: issues at jboss.org (Michael Musgrove (Jira))
Date: Fri, 31 May 2019 14:09:00 -0400 (EDT)
Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3151) Fix for JBTM-3146 causes
 a regression when building with JDK 11
In-Reply-To: <JIRA.12810377.1559326080000@Atlassian.JIRA>
References: <JIRA.12810377.1559326080000@Atlassian.JIRA>
	<JIRA.12810377.1559326080475@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12810377.1559326080000.57002.1559326140077@Atlassian.JIRA>

Michael Musgrove created JBTM-3151:
--------------------------------------

             Summary: Fix for JBTM-3146 causes a regression when building with JDK 11 
                 Key: JBTM-3151
                 URL: https://issues.jboss.org/browse/JBTM-3151
             Project: JBoss Transaction Manager
          Issue Type: Bug
          Components: Build System
    Affects Versions: 5.9.5.Final
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 5.next


The fix for JBTM-3146 (Better support for Quarkus) uses byte code inject at build time and this fails on JDK 11:

[ERROR] Failed to execute goal org.jboss.maven.plugins:maven-injection-plugin:1.0.2:bytecode (default) on project common: Unable to resolve method [com.arjuna.common.util.ConfigurationInfo#getSourceId]: java.io.IOException: invalid constant type: 18 -> [Help 1]





--
This message was sent by Atlassian Jira
(v7.12.1#712002)