[JBoss JIRA] (JBTM-3154) CI failure: AS_TESTS compilation failure on JDK8 with duplicate duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3154?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka closed JBTM-3154.
----------------------------------
> CI failure: AS_TESTS compilation failure on JDK8 with duplicate duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-3154
> URL: https://issues.jboss.org/browse/JBTM-3154
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Fix For: 5.9.6.Final
>
>
> Running the CDI tests as
> {code}
> export JBOSS_HOME=...
> ./tools/maven/bin/mvn -B -s "./tools/maven/conf/settings.xml" -Dbpa=centos54x64 test -f ./ArjunaJTA/cdi/pom.xml -B -Parq -Duse.valgrind=false
> {code}
> {code}
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/DelegatingTransactionManager.java:[49,17] duplicate class: com.arjuna.ats.jta.cdi.DelegatingTransactionManager
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/JTASupplier.java:[42,7] duplicate class: com.arjuna.ats.jta.cdi.JTASupplier
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorMandatory.java:[44,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/NarayanaTransactionManager.java:[70,1] duplicate class: com.arjuna.ats.jta.cdi.NarayanaTransactionManager
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorSupports.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorSupports
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionExtension.java:[56,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionExtension
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorNever.java:[44,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNever
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionScopeCleanup.java:[14,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionScopeCleanup
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/TransactionContext.java:[52,8] duplicate class: com.arjuna.ats.jta.cdi.TransactionContext
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorNotSupported.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorNotSupported
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorRequired.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/NarayanaTransactionSynchronizationRegistry.java:[59,1] duplicate class: com.arjuna.ats.jta.cdi.NarayanaTransactionSynchronizationRegistry
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/DelegatingTransactionSynchronizationRegistry.java:[49,17] duplicate class: com.arjuna.ats.jta.cdi.DelegatingTransactionSynchronizationRegistry
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorRequiresNew.java:[40,8] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequiresNew
> [ERROR] /home/jenkins/workspace/narayana/PROFILE/AS_TESTS/jdk/jdk8.latest/label/linux/ArjunaJTA/cdi/classes/com/arjuna/ats/jta/cdi/transactional/TransactionalInterceptorBase.java:[59,17] duplicate class: com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3157) LRA participant does not respect JAX-RS path definitions
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3157?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3157:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.9.6.Final
Resolution: Done
> LRA participant does not respect JAX-RS path definitions
> --------------------------------------------------------
>
> Key: JBTM-3157
> URL: https://issues.jboss.org/browse/JBTM-3157
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.5.Final
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.9.6.Final
>
>
> When LRA participant defines paths for participant methods like this:
> {code:java}
> @PUT
> @Path("compensate")
> @Compensate
> public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) {
> System.out.println("Compensate: " + lraId);
> }
> {code}
> instead of:
> {code:java}
> @PUT
> @Path("/compensate")
> @Compensate
> public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) {
> System.out.println("Compensate: " + lraId);
> }
> {code}
> The participant methods are never executed because the constructed URL is not valid. However, even the first code snippet is still a valid JAX-RS resource definition and thus it should be respected.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3134) Init store failure could provide more information in the exception than just NullPointer
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3134?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka closed JBTM-3134.
----------------------------------
> Init store failure could provide more information in the exception than just NullPointer
> ----------------------------------------------------------------------------------------
>
> Key: JBTM-3134
> URL: https://issues.jboss.org/browse/JBTM-3134
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Fix For: 5.9.6.Final
>
>
> When `StorageManager` fails with to initialize store instance the error comes as `NullPointerException`. That's not much informative. The exception should says what happens. The example of the exception thrown now is[1]. The more information then is available in the log but still exception should give some basic idea what happens not just `NullPointerException`.
> [1]
> {code}
> java.lang.NullPointerException
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:159)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.setupStore(StoreManager.java:136)
> at com.hp.mwtests.ts.arjuna.abstractrecords.CadaverRecordUnitTest.test(CadaverRecordUnitTest.java:49)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3134) Init store failure could provide more information in the exception than just NullPointer
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3134?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3134:
-----------------------------------
Fix Version/s: 5.9.6.Final
> Init store failure could provide more information in the exception than just NullPointer
> ----------------------------------------------------------------------------------------
>
> Key: JBTM-3134
> URL: https://issues.jboss.org/browse/JBTM-3134
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Fix For: 5.9.6.Final
>
>
> When `StorageManager` fails with to initialize store instance the error comes as `NullPointerException`. That's not much informative. The exception should says what happens. The example of the exception thrown now is[1]. The more information then is available in the log but still exception should give some basic idea what happens not just `NullPointerException`.
> [1]
> {code}
> java.lang.NullPointerException
> at com.arjuna.ats.arjuna.objectstore.StoreManager.initStore(StoreManager.java:159)
> at com.arjuna.ats.arjuna.objectstore.StoreManager.setupStore(StoreManager.java:136)
> at com.hp.mwtests.ts.arjuna.abstractrecords.CadaverRecordUnitTest.test(CadaverRecordUnitTest.java:49)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3138:
-----------------------------------
Fix Version/s: 5.9.6.Final
> XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-3138
> URL: https://issues.jboss.org/browse/JBTM-3138
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: XTS
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Fix For: 5.9.6.Final
>
> Attachments: server.log, stacktrace.txt
>
>
> As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant.
> In scenario
> * WS call to the WFLY server
> * inbound bridge injects the JTA transactions as subordinate under the WS AT one
> * prepare is called and the 2PC phase finishes
> * commit phase starts and JVM crashes
> * restart of WFLY server
> * recovery is expected to commit the participants
> the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed.
> This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3138) XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3138?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka closed JBTM-3138.
----------------------------------
> XTS txbridge does not run commit when 1PC is used, prepared phase fails on crash recovery later
> -----------------------------------------------------------------------------------------------
>
> Key: JBTM-3138
> URL: https://issues.jboss.org/browse/JBTM-3138
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: XTS
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Fix For: 5.9.6.Final
>
> Attachments: server.log, stacktrace.txt
>
>
> As it seems the crashed inbound txbridge participant finished with rollback after recovery is run on the prepared participant.
> In scenario
> * WS call to the WFLY server
> * inbound bridge injects the JTA transactions as subordinate under the WS AT one
> * prepare is called and the 2PC phase finishes
> * commit phase starts and JVM crashes
> * restart of WFLY server
> * recovery is expected to commit the participants
> the outcome is rollback for the participant not the commit as it's expected. This way the data consistency could be harmed.
> This was discussed at the forum https://developer.jboss.org/thread/279243 as follow-up to the issue JBTM-3079.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3139) XTS localjunit xtstest at XTS/localjunit/xtstest are never run
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3139?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka closed JBTM-3139.
----------------------------------
> XTS localjunit xtstest at XTS/localjunit/xtstest are never run
> --------------------------------------------------------------
>
> Key: JBTM-3139
> URL: https://issues.jboss.org/browse/JBTM-3139
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: XTS
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Fix For: 5.9.6.Final
>
>
> Tests in module {{XTS/localjunit/xtstest}} are never run. Even when used the `-Parq` the tests invocation is skipped.
> {code}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ xtstest ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- byteman-rulecheck-maven-plugin:4.0.4:rulecheck (rulecheck) @ xtstest ---
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.1:copy-dependencies (copy-dependencies) @ xtstest ---
> [INFO] Copying byteman-4.0.4.jar to /home/jenkins/workspace/btny-pulls-narayana/PROFILE/XTS/jdk/jdk8.latest/label/linux/XTS/localjunit/xtstest/target/lib/byteman.jar
> [INFO] Copying byteman-submit-4.0.4.jar to /home/jenkins/workspace/btny-pulls-narayana/PROFILE/XTS/jdk/jdk8.latest/label/linux/XTS/localjunit/xtstest/target/lib/byteman-submit.jar
> [INFO]
> [INFO] --- maven-surefire-plugin:2.20:test (default-test) @ xtstest ---
> [INFO] Tests are skipped.
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months
[JBoss JIRA] (JBTM-3139) XTS localjunit xtstest at XTS/localjunit/xtstest are never run
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/JBTM-3139?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka updated JBTM-3139:
-----------------------------------
Fix Version/s: 5.9.6.Final
> XTS localjunit xtstest at XTS/localjunit/xtstest are never run
> --------------------------------------------------------------
>
> Key: JBTM-3139
> URL: https://issues.jboss.org/browse/JBTM-3139
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: XTS
> Affects Versions: 5.9.5.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Fix For: 5.9.6.Final
>
>
> Tests in module {{XTS/localjunit/xtstest}} are never run. Even when used the `-Parq` the tests invocation is skipped.
> {code}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ xtstest ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- byteman-rulecheck-maven-plugin:4.0.4:rulecheck (rulecheck) @ xtstest ---
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.1:copy-dependencies (copy-dependencies) @ xtstest ---
> [INFO] Copying byteman-4.0.4.jar to /home/jenkins/workspace/btny-pulls-narayana/PROFILE/XTS/jdk/jdk8.latest/label/linux/XTS/localjunit/xtstest/target/lib/byteman.jar
> [INFO] Copying byteman-submit-4.0.4.jar to /home/jenkins/workspace/btny-pulls-narayana/PROFILE/XTS/jdk/jdk8.latest/label/linux/XTS/localjunit/xtstest/target/lib/byteman-submit.jar
> [INFO]
> [INFO] --- maven-surefire-plugin:2.20:test (default-test) @ xtstest ---
> [INFO] Tests are skipped.
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
4 years, 8 months