From issues at jboss.org Fri Apr 1 03:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2640) Add username and password to JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2640. --------------------------------- > Add username and password to JmsXAResourceRecoveryHelper > -------------------------------------------------------- > > Key: JBTM-2640 > URL: https://issues.jboss.org/browse/JBTM-2640 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.2.Final > > > In some scenarios user name and password might be needed during the recovery of JMS resources. For those cases JmsXAResourceRecoveryHelper should be able to take username and password as an argument and use them when creating connections. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2649. --------------------------------- > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.15.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2638. --------------------------------- > Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover > ------------------------------------------------------------------------------------ > > Key: JBTM-2638 > URL: https://issues.jboss.org/browse/JBTM-2638 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.2.Final > > > Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2633) Arquillian server startup timeout should be configurable in tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2633. --------------------------------- > Arquillian server startup timeout should be configurable in tests > ----------------------------------------------------------------- > > Key: JBTM-2633 > URL: https://issues.jboss.org/browse/JBTM-2633 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > Fix For: 5.3.2.Final > > > Arquillian configuration for tests which lays in _arquillian.xml_ currently does not permit changing timeou for server startup. Default timeout for server startup is 60 seconds. If server is not up and running till that time Arquillian stops the serve process and {{LifecycleException}} is thrown informing that server was not started. > If tests (like txbridge or xts) are run with container which uses _jdbc object store_ and connection to database is slow. It could happen that 60 seconds is not enough for serve being started and tests start to fail. The easy solution is to wait a bit more for server would be started. > Then add configuration property {{startupTimeoutInSeconds}} to {{arquillian.xml}} files which are configured to start jboss/wildfly server and let user to configure the option. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2626. --------------------------------- > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.2.Final > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Write an atomic app that uses JTS and JacORB containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2298. --------------------------------- > Write an atomic app that uses JTS and JacORB containers > ------------------------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.3.2.Final > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2648: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used > ------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2648 > URL: https://issues.jboss.org/browse/JBTM-2648 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: TEST-org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12.txt, testoutput.zip > > > When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2650: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Remove typo from BAControler interface and its implementations > -------------------------------------------------------------- > > Key: JBTM-2650 > URL: https://issues.jboss.org/browse/JBTM-2650 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2647) Extend compensations BAControler to allow enlistment of handlers by instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2647: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Extend compensations BAControler to allow enlistment of handlers by instance > ---------------------------------------------------------------------------- > > Key: JBTM-2647 > URL: https://issues.jboss.org/browse/JBTM-2647 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Currently BAControler allows enlistment of handler only by class. It later creates instances using those classes when finishing the compensating transaction. Because of that it should be easy to allow enlisting of instances. This would allow using labdas when implementing handlers. Also instance could carry some extra information needed to compensate the transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2643: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 5.next > > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2641) Add localisation to JMS module warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2641: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Add localisation to JMS module warnings > --------------------------------------- > > Key: JBTM-2641 > URL: https://issues.jboss.org/browse/JBTM-2641 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Warning messages in JMS modules should be localised same as other modules in ArjunaJTA. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2639: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2634: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2629: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2632: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2623: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > 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:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2624: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2619) Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2619: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) > -------------------------------------------------------------------------- > > Key: JBTM-2619 > URL: https://issues.jboss.org/browse/JBTM-2619 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > It should be with the recovery example -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2606: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2622: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:25:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2605) Narayana Spring integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2605: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Narayana Spring integration > --------------------------- > > Key: JBTM-2605 > URL: https://issues.jboss.org/browse/JBTM-2605 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, Documentation, JTA > Reporter: Gytis Trikleris > Fix For: 5.next > > > This is a wrapper for all subtasks related with Spring integration. > As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2571: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2553: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2542: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2498: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2480: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2458: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2206: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2203: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2115: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-1804: ---------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 03:26:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 03:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-223: --------------------------------- Fix Version/s: 5.next (was: 5.3.2.Final) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 05:08:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 1 Apr 2016 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2642: ----------------------------------- Forum Reference: https://developer.jboss.org/message/953835 > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.later > > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 05:17:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 1 Apr 2016 05:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2651) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: Tomas Hofman created JBTM-2651: ---------------------------------- Summary: "number-of-application-rollbacks" statistic counted multiple times during single rollback Key: JBTM-2651 URL: https://issues.jboss.org/browse/JBTM-2651 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Reporter: Tomas Hofman Assignee: Tomas Hofman Fix For: 5.next During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 1 06:48:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 1 Apr 2016 06:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2606: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/spring-projects/spring-boot/pull/5552 > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 4 07:32:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 4 Apr 2016 07:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2629: ---------------------------------- Fix Version/s: (was: 5.next) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 4 12:05:00 2016 From: issues at jboss.org (Mark Little (JIRA)) Date: Mon, 4 Apr 2016 12:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186142#comment-13186142 ] Mark Little commented on JBTM-2642: ----------------------------------- Our version was based on the initial draft of 1.2 and then the final version. However, we had some ifdefs in the original file (a template file) so we could support different versions due to compliance issues with ORBs. It's possible the ifdef locations produced a different ordering or that there were changes in the standards we didn't track. > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.later > > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 7 03:02:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 7 Apr 2016 03:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2606: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 7 03:03:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 7 Apr 2016 03:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188112#comment-13188112 ] Gytis Trikleris commented on JBTM-2606: --------------------------------------- This feature was merged into the Spring Boot master: https://github.com/spring-projects/spring-boot/commit/a2adc5a1304f2eb24127bf60e6ad7dd50643fc7c > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 8 07:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 8 Apr 2016 07:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2652) Include STM javadocs on narayana.io In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2652: ----------------------------------- Summary: Include STM javadocs on narayana.io Key: JBTM-2652 URL: https://issues.jboss.org/browse/JBTM-2652 Project: JBoss Transaction Manager Issue Type: Task Components: Documentation, STM Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Apr 10 22:07:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sun, 10 Apr 2016 22:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189485#comment-13189485 ] RH Bugzilla Integration commented on JBTM-2579: ----------------------------------------------- Brad Maxwell changed the Status of [bug 1325726|https://bugzilla.redhat.com/show_bug.cgi?id=1325726] from NEW to MODIFIED > Throw XAException in XATerminator::commit if a wrapped resource fails transiently > --------------------------------------------------------------------------------- > > Key: JBTM-2579 > URL: https://issues.jboss.org/browse/JBTM-2579 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.31, 5.2.9.Final > > > It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome. > The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 04:17:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Mon, 11 Apr 2016 04:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated JBTM-2643: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.3.2.Final (was: 5.next) Resolution: Done > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 5.3.2.Final > > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 06:56:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 11 Apr 2016 06:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2641) Add localisation to JMS module warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #998 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add localisation to JMS module warnings > --------------------------------------- > > Key: JBTM-2641 > URL: https://issues.jboss.org/browse/JBTM-2641 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Warning messages in JMS modules should be localised same as other modules in ArjunaJTA. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 07:11:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 07:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2649: --------------------------------- Not in 5.2.15.Final! > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.15.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 07:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 07:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2649: -------------------------------- Fix Version/s: 5.2.16.Final (was: 5.2.15.Final) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 07:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 07:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2649: -------------------------------- Affects Version/s: 5.2.15.Final > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 07:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 07:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2649. --------------------------------- Resolution: Done > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.2.Final, 5.2.16.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 07:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 07:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2649. ------------------------------- > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.2.15.Final > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.16.Final, 5.3.2.Final > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 09:04:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 11 Apr 2016 09:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #999 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Remove typo from BAControler interface and its implementations > -------------------------------------------------------------- > > Key: JBTM-2650 > URL: https://issues.jboss.org/browse/JBTM-2650 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 09:17:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 11 Apr 2016 09:17:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2646: ----------------------------------- Fix Version/s: 5.next > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 09:50:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 09:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189876#comment-13189876 ] Tom Jenkinson commented on JBTM-2639: ------------------------------------- http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/159/ > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 11 09:50:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 11 Apr 2016 09:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2639: -------------------------------- Priority: Minor (was: Major) > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 12 04:55:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 12 Apr 2016 04:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2650: ---------------------------------- Status: Open (was: Pull Request Sent) > Remove typo from BAControler interface and its implementations > -------------------------------------------------------------- > > Key: JBTM-2650 > URL: https://issues.jboss.org/browse/JBTM-2650 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 13 09:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 13 Apr 2016 09:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2639. ---------------------------------- Release Notes Text: I was trying to disable debug using QA_TRACE=0 but unset QA_TRACE is the correct way to disable it. Resolution: Cannot Reproduce > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 14 05:55:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 14 Apr 2016 05:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2653) Make the service context id for JTS coordinator propagation configurable In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2653: -------------------------------------- Summary: Make the service context id for JTS coordinator propagation configurable Key: JBTM-2653 URL: https://issues.jboss.org/browse/JBTM-2653 Project: JBoss Transaction Manager Issue Type: Task Components: JTS Affects Versions: 5.3.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional JTS transaction propagation uses a CORBA service context to transmit the coordinator object reference. We use a proprietary id to identify this context but if we want to interoperate with foreign transaction managers we need to use the standard value of zero. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 14 06:06:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 14 Apr 2016 06:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191709#comment-13191709 ] Michael Musgrove commented on JBTM-2623: ---------------------------------------- I have created a branch that fixes the blockers (https://github.com/jbosstm/narayana/tree/JBTM-223/interop) and also a wilfly branch that removes the EJB interceptor that blocks the import of foreign transactions (https://github.com/jbosstm/jboss-as/tree/5_BRANCH_JBTM-223). The interop/README.md file in the JBTM-223 branch describes how to test transaction propagation and recovery. > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > 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:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 18 09:46:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 18 Apr 2016 09:46:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193154#comment-13193154 ] Michael Musgrove commented on JBTM-2440: ---------------------------------------- I asked [~adinn] to provide an opinion about whether it could be the annotation rather than the agent loading functionality that is the root cause of the problem and he suspects that it is most likely a bug in the dynamic agent loading behaviour in the J9 compiler. He also gave a good analysis of the issue which I am including here: {quote} I downloaded IBM's Java 7 SDK and tried to use it to build Byteman. That's enough to thoroughly test the use of the agent. The tests on the Byteman agent maven module are configured to install the agent from the command line using the -javaagent option (I do that rather than use the BMUnitRunner to auto-load because I don't want failures in BMUnit to stop the agent jar being built). These tests all worked ok. So, the IBM JDK does support all the functionality of the Byteman agent when you load it from the command line. The maven tests in the BMUnit maven module rely the BMUnitRunner annotation to auto-install the agent into an already running test JVM and this is what failed. The error output is attached. As you can see from the first exception trace the IBM JVM does implement dynamic loading -- the Attach operation is fielded and J9 tries to install the agent by executing com.ibm.tools.attach.javaSE.Attachment.loadAgentLibrary If you look at the cause of the exception you can see that this eventually calls into org.jboss.byteman.agent.Main.premain which is the Byteman entry point. This tries to register its ClassFileTransformer (InstrumentationImpl.addTransformer) and at this point J9 blows up. It is objecting to the agent's request for the ClassFileTransformer to be installed as a 'retransformable' transformer. That means it wants to be able to handle retransformations of existing classes as well as being given a chance to modify newly loaded classes. This seems a tad odd because when the Byteman agent is loaded on the command line it also asks its ClassFileTransformer to be installed as a retransformable transformer. So, the refusal by J9 must be some sort of policy decision on its part. I suspect that this may be a performance hack -- J9 may be willing to not perform certain optimizations in order to allow for retransformers if you install them from the get go but otherwise may decide to switch on optimizations that mean subsequent use of retransformers won't work. Whatever the reason IBM have done this you are snookered until you can get them to remove this restriction. n.b. it is a legitimate (i.e. JVMTI agent spec-compliant) behaviour but it's not exactly very useful. I will make eqnuiries to see if I can talk to someone in IBM and get this removed or, at least, find a way to relax it but I am not sure I will have any traction. I think there is only one workaround which will fix this if you want to use BMUnit on both OpenJDK/Oracle and IBM. You will need to switch to loading the agent from the command line (whatever JVM you are using). To do this you need to: i) install the agent on the command line of the test JVM by configuring java command line argument -javaagent:/path/to/byteman.jar=listener:true ii) stop BMUnit from loading the agent by adding adding the property setting -Dorg.jboss.byteman.contrib.bmunit.agent.inhibit n.b. you will need to build the path to the byteman jar by referencing the relevant dependency in your maven repo dir. you should be able to do that using by substituting maven property values (repo dir + byteman dependency version) into the path n.b. if you don't do the load yourself then you may want to set some other -javaagent options and/or Byteman system properties. The auto load will do the equivalent of adding boot:/path/to/byteman.jar to the -javaagent line and adding -Dorg.jboss.byteman.allow.config.update as a system property setting. The former allows you to inject into JDK runtime classes. The latter allows BMUnit to pay heed to your any options specified using a BMUnitConfig annotation on your test class. regards, Andrew Dinn {quote} > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 18 10:24:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 18 Apr 2016 10:24:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2636: -------------------------------- Fix Version/s: 4.17.32 (was: 4.17.31) > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 18 10:24:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 18 Apr 2016 10:24:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2636. ------------------------------- > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 18 10:25:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 18 Apr 2016 10:25:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2636. ------------------------------- Resolution: Done > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 18 10:25:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 18 Apr 2016 10:25:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2636: --------------------------------- Assignee: Tom Jenkinson > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 19 09:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 19 Apr 2016 09:15:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2646: -------------------------------- Priority: Blocker (was: Optional) > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 19 11:00:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 19 Apr 2016 11:00:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2645) XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2645: ----------------------------------- Assignee: Tom Jenkinson > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure > ---------------------------------------------------------------------------------- > > Key: JBTM-2645 > URL: https://issues.jboss.org/browse/JBTM-2645 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > {code} > Running com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.636 sec <<< FAILURE! - in com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > testTimelyXAResourceRecoveryHelperRemoval2(com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest) Time elapsed: 2.616 sec <<< FAILURE! > java.lang.AssertionError: helper2 removed in wrong state expected:<2> but was:<0> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval(XARecoveryModuleHelpersUnitTest.java:212) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2(XARecoveryModuleHelpersUnitTest.java:64) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 19 11:00:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 19 Apr 2016 11:00:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2645) XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2645: -------------------------------- Fix Version/s: 5.next > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure > ---------------------------------------------------------------------------------- > > Key: JBTM-2645 > URL: https://issues.jboss.org/browse/JBTM-2645 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > {code} > Running com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.636 sec <<< FAILURE! - in com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > testTimelyXAResourceRecoveryHelperRemoval2(com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest) Time elapsed: 2.616 sec <<< FAILURE! > java.lang.AssertionError: helper2 removed in wrong state expected:<2> but was:<0> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval(XARecoveryModuleHelpersUnitTest.java:212) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2(XARecoveryModuleHelpersUnitTest.java:64) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 19 11:20:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 19 Apr 2016 11:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2645) XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2645. ------------------------------- Fix Version/s: (was: 5.next) Resolution: Won't Fix I am closing this issue. It is a timing issue, likely because main thread woke too quickly (100 millis) and was seen on code coverage job which runs slow due to running coverage checking. If necessary increase backoff time to 1000 and double xAResourcesSleepMillis. > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure > ---------------------------------------------------------------------------------- > > Key: JBTM-2645 > URL: https://issues.jboss.org/browse/JBTM-2645 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > {code} > Running com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.636 sec <<< FAILURE! - in com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest > testTimelyXAResourceRecoveryHelperRemoval2(com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest) Time elapsed: 2.616 sec <<< FAILURE! > java.lang.AssertionError: helper2 removed in wrong state expected:<2> but was:<0> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval(XARecoveryModuleHelpersUnitTest.java:212) > at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2(XARecoveryModuleHelpersUnitTest.java:64) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 19 13:06:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 19 Apr 2016 13:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2654) Provide a method to restart the StoreManager In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2654: -------------------------------------- Summary: Provide a method to restart the StoreManager Key: JBTM-2654 URL: https://issues.jboss.org/browse/JBTM-2654 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Transaction Core Affects Versions: 5.3.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional In the tooling I would like to be able to dynamically change object stores but the various stores (actionStore, stateStore and communicationStore) are cached and the StoreManager.shutdown() method does not null these variables so they can never be reinitialised. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 10:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 10:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2655) QA suite failure: jdbcresources01_pgsql_jndi (JDBC store) In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2655: ----------------------------------- Summary: QA suite failure: jdbcresources01_pgsql_jndi (JDBC store) Key: JBTM-2655 URL: https://issues.jboss.org/browse/JBTM-2655 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Reporter: Tom Jenkinson Priority: Minor Fix For: 5.later http://albany.eng.hst.ams2.redhat.com/job/narayana-jdbcobjectstore/DB_TYPE=db2,jdk=jdk7.latest,slave=linux/164/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 10:30:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 10:30:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2655) QA suite failure: TestGroup_txcore_recovery (JDBC store) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2655: -------------------------------- Summary: QA suite failure: TestGroup_txcore_recovery (JDBC store) (was: QA suite failure: jdbcresources01_pgsql_jndi (JDBC store)) > QA suite failure: TestGroup_txcore_recovery (JDBC store) > -------------------------------------------------------- > > Key: JBTM-2655 > URL: https://issues.jboss.org/browse/JBTM-2655 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Tom Jenkinson > Priority: Minor > Fix For: 5.later > > > http://albany.eng.hst.ams2.redhat.com/job/narayana-jdbcobjectstore/DB_TYPE=db2,jdk=jdk7.latest,slave=linux/164/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 10:30:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 10:30:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2655) QA suite failure: TestGroup_txcore_recovery (JDBC store) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2655: -------------------------------- Description: http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-jdbcobjectstore/164/DB_TYPE=db2,jdk=jdk7.latest,slave=linux/consoleFull (was: http://albany.eng.hst.ams2.redhat.com/job/narayana-jdbcobjectstore/DB_TYPE=db2,jdk=jdk7.latest,slave=linux/164/console) > QA suite failure: TestGroup_txcore_recovery (JDBC store) > -------------------------------------------------------- > > Key: JBTM-2655 > URL: https://issues.jboss.org/browse/JBTM-2655 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Tom Jenkinson > Priority: Minor > Fix For: 5.later > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-jdbcobjectstore/164/DB_TYPE=db2,jdk=jdk7.latest,slave=linux/consoleFull -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 11:47:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 21 Apr 2016 11:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2656: -------------------------------------- Summary: XATerminatorImple#recover should return an empty array in preference to null Key: JBTM-2656 URL: https://issues.jboss.org/browse/JBTM-2656 Project: JBoss Transaction Manager Issue Type: Bug Components: JCA Affects Versions: 5.3.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Description: The javadoc for the XATerminator recover method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Description: The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. was: The javadoc for the XATerminator recover method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Steps to Reproduce: (was: The [javadoc for the XATerminator recover |http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-] method says the resource manager should return zero or more XIDs or throw an exception but [our implementation of it|https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L309] returns null if there are no in doubt Xids.) > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195364#comment-13195364 ] Tom Jenkinson commented on JBTM-2656: ------------------------------------- I removed the steps to reproduce as it seemed more like a description of the problem and the description itself was blank - hope you don't mind. > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Comment: was deleted (was: I removed the steps to reproduce as it seemed more like a description of the problem and the description itself was blank - hope you don't mind.) > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195366#comment-13195366 ] Tom Jenkinson commented on JBTM-2656: ------------------------------------- By returning null we are returning zero Xids, I am inclined to say we are therefore compliant. That said a zero sized array would simplify our own testing to I am receptive to the change but not under compliance arguments - hence downgrading to Minor. > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover should return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Priority: Minor (was: Major) > XATerminatorImple#recover should return an empty array in preference to null > ---------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Apr 21 12:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 21 Apr 2016 12:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover could return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Summary: XATerminatorImple#recover could return an empty array in preference to null (was: XATerminatorImple#recover should return an empty array in preference to null) > XATerminatorImple#recover could return an empty array in preference to null > --------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Apr 24 23:17:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Sun, 24 Apr 2016 23:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2657) Missing narayana-osgi-jta artifact with the release profile In-Reply-To: References: Message-ID: Amos Feng created JBTM-2657: ------------------------------- Summary: Missing narayana-osgi-jta artifact with the release profile Key: JBTM-2657 URL: https://issues.jboss.org/browse/JBTM-2657 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Apr 24 23:18:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Sun, 24 Apr 2016 23:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2657) Missing narayana-osgi-jta artifact with the release profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2657: ---------------------------- Fix Version/s: 5.next > Missing narayana-osgi-jta artifact with the release profile > ----------------------------------------------------------- > > Key: JBTM-2657 > URL: https://issues.jboss.org/browse/JBTM-2657 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Labels: JTA, OSGI > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Apr 24 23:18:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Sun, 24 Apr 2016 23:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2657) Missing narayana-osgi-jta artifact with the release profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2657: ---------------------------- Labels: JTA OSGI (was: ) > Missing narayana-osgi-jta artifact with the release profile > ----------------------------------------------------------- > > Key: JBTM-2657 > URL: https://issues.jboss.org/browse/JBTM-2657 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Labels: JTA, OSGI > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 25 01:57:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 25 Apr 2016 01:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2657) Missing narayana-osgi-jta artifact with the release profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1002 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Missing narayana-osgi-jta artifact with the release profile > ----------------------------------------------------------- > > Key: JBTM-2657 > URL: https://issues.jboss.org/browse/JBTM-2657 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Labels: JTA, OSGI > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 25 06:12:02 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 25 Apr 2016 06:12:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196356#comment-13196356 ] RH Bugzilla Integration commented on JBTM-2636: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1316270|https://bugzilla.redhat.com/show_bug.cgi?id=1316270] from MODIFIED to ON_QA > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.32 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 25 06:12:03 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 25 Apr 2016 06:12:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2120) Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196357#comment-13196357 ] RH Bugzilla Integration commented on JBTM-2120: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1316270|https://bugzilla.redhat.com/show_bug.cgi?id=1316270] from MODIFIED to ON_QA > Add a deferred exceptions to the rollback exception if the first resource throws a heuristic rollback > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2120 > URL: https://issues.jboss.org/browse/JBTM-2120 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.2.6.Final > > > Pull https://github.com/jbosstm/narayana/pull/598 added deferred throwables in case the XAR::end fails during commit. It doesn't handle the case of the HEURISTIC_ROLLBACK of a first resource where Narayana rolls back the remaining participants and then clears the failed/heuristic lists (and marks the txn as rolled back). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 25 06:13:01 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 25 Apr 2016 06:13:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2579) Throw XAException in XATerminator::commit if a wrapped resource fails transiently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196378#comment-13196378 ] RH Bugzilla Integration commented on JBTM-2579: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1325726|https://bugzilla.redhat.com/show_bug.cgi?id=1325726] from MODIFIED to ON_QA > Throw XAException in XATerminator::commit if a wrapped resource fails transiently > --------------------------------------------------------------------------------- > > Key: JBTM-2579 > URL: https://issues.jboss.org/browse/JBTM-2579 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.31, 5.2.9.Final > > > It is possible for a resource that we are wrapping to return say XA_RETRY or XA_RMFAIL and therefore end up in the BasicAction failed list. However there is no error returned from commit in this circumstance as the recovery manager should ensure a consistent outcome. > The reason this becomes a problem for JTA and XATerminator in particular is that as no error is returned a parent coordinator will assume the branch completed successfully. In the future when it calls XATerminator::recover though this branch will be returned and detected as an orphan. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Apr 25 06:13:01 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 25 Apr 2016 06:13:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2575) When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196379#comment-13196379 ] RH Bugzilla Integration commented on JBTM-2575: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1289386|https://bugzilla.redhat.com/show_bug.cgi?id=1289386] from MODIFIED to ON_QA > When checking for orphaned subordinate transactions in the middle of a tree branches that are eligible for orphan detection will be rolled back > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2575 > URL: https://issues.jboss.org/browse/JBTM-2575 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.31, 5.2.9.Final > > > There is a check in the subordinate orphan detection that not only checks for matching gtrid but also for matching subordinate name. This will not match correctly for an intermediary node. E.g. > a->b b->c > When b scans c the xid it gets back will have subordinate name of c, b will look in its object store and match the subordinate on gtrid but the subordinate node ID in b subordinateatomicaction will be "b". > This check is actually superfluous anyway. We already know that the Xid returned from c was for b because of transport level checks. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:30:00 2016 From: issues at jboss.org (Alexis Hassler (JIRA)) Date: Tue, 26 Apr 2016 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: Alexis Hassler created JBTM-2658: ------------------------------------ Summary: Implement JMS integration classes for MessageListener Key: JBTM-2658 URL: https://issues.jboss.org/browse/JBTM-2658 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTA Affects Versions: 5.3.2.Final Reporter: Alexis Hassler Priority: Minor The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 26 Apr 2016 09:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197197#comment-13197197 ] Tom Jenkinson commented on JBTM-2658: ------------------------------------- Hi Alexis, I think you might be in the wrong place, this is the transaction manager component not the JMS component? Maybe you could talk to the Artemis team? Unless I misunderstood but in which case I recommend a discussion here first: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d > Implement JMS integration classes for MessageListener > ----------------------------------------------------- > > Key: JBTM-2658 > URL: https://issues.jboss.org/browse/JBTM-2658 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Priority: Minor > > The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:34:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 26 Apr 2016 09:34:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2658. ------------------------------- Resolution: Migrated to another ITS > Implement JMS integration classes for MessageListener > ----------------------------------------------------- > > Key: JBTM-2658 > URL: https://issues.jboss.org/browse/JBTM-2658 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Priority: Minor > > The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:36:00 2016 From: issues at jboss.org (Alexis Hassler (JIRA)) Date: Tue, 26 Apr 2016 09:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197201#comment-13197201 ] Alexis Hassler commented on JBTM-2658: -------------------------------------- I've already done some code to try it. I've added a MessageListenerProxy for that. It has an impact on the ConnectionProxy class because it has to instantiate a SessionProxy even if the transaction has not started yet. > Implement JMS integration classes for MessageListener > ----------------------------------------------------- > > Key: JBTM-2658 > URL: https://issues.jboss.org/browse/JBTM-2658 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Priority: Minor > > The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:39:00 2016 From: issues at jboss.org (Alexis Hassler (JIRA)) Date: Tue, 26 Apr 2016 09:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197204#comment-13197204 ] Alexis Hassler commented on JBTM-2658: -------------------------------------- Hi Tom, It's not related to Artemis at all but to the org.jboss.narayana.jta.jms package, and to this previous ticket : https://issues.jboss.org/browse/JBTM-2616 OK, I'll start a discussion on the forum. > Implement JMS integration classes for MessageListener > ----------------------------------------------------- > > Key: JBTM-2658 > URL: https://issues.jboss.org/browse/JBTM-2658 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Priority: Minor > > The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 09:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 26 Apr 2016 09:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2658) Implement JMS integration classes for MessageListener In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197210#comment-13197210 ] Tom Jenkinson commented on JBTM-2658: ------------------------------------- Thanks Alexis, I look forward to reading more about your proposal and hopefully working with you to share it with the community. > Implement JMS integration classes for MessageListener > ----------------------------------------------------- > > Key: JBTM-2658 > URL: https://issues.jboss.org/browse/JBTM-2658 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Priority: Minor > > The new JMS integration classes are working fine with a Publisher or a simple Consumer, but not with MessageListener. It would be nice to be able to implement something like a MDB without JavaEE. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:46:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2659) narayana-osgi-jta build bundle warings In-Reply-To: References: Message-ID: Amos Feng created JBTM-2659: ------------------------------- Summary: narayana-osgi-jta build bundle warings Key: JBTM-2659 URL: https://issues.jboss.org/browse/JBTM-2659 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng There are three warning when building the bundle. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:47:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2659) narayana-osgi-jta build bundle warings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2659: ---------------------------- Fix Version/s: 5.next > narayana-osgi-jta build bundle warings > -------------------------------------- > > Key: JBTM-2659 > URL: https://issues.jboss.org/browse/JBTM-2659 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > There are three warning when building the bundle. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:48:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: Amos Feng created JBTM-2660: ------------------------------- Summary: multiple jars provide the same package:javax/transaction Key: JBTM-2660 URL: https://issues.jboss.org/browse/JBTM-2660 Project: JBoss Transaction Manager Issue Type: Sub-task Reporter: Amos Feng Assignee: Amos Feng [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:49:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2659) narayana-osgi-jta build bundle warings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2659: ---------------------------- Issue Type: Bug (was: Task) > narayana-osgi-jta build bundle warings > -------------------------------------- > > Key: JBTM-2659 > URL: https://issues.jboss.org/browse/JBTM-2659 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > There are three warning when building the bundle. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:49:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2661) Unknown directive cardinality: in Require-Capability In-Reply-To: References: Message-ID: Amos Feng created JBTM-2661: ------------------------------- Summary: Unknown directive cardinality: in Require-Capability Key: JBTM-2661 URL: https://issues.jboss.org/browse/JBTM-2661 Project: JBoss Transaction Manager Issue Type: Sub-task Reporter: Amos Feng Assignee: Amos Feng [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Unknown directive cardinality: in Require-Capability, allowed directives are effective:,resolution:,filter:, and 'x-*'. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:50:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2662) Export org.jboss.tm, has 1, private references [org.jboss.logging] In-Reply-To: References: Message-ID: Amos Feng created JBTM-2662: ------------------------------- Summary: Export org.jboss.tm, has 1, private references [org.jboss.logging] Key: JBTM-2662 URL: https://issues.jboss.org/browse/JBTM-2662 Project: JBoss Transaction Manager Issue Type: Sub-task Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Apr 26 23:50:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 26 Apr 2016 23:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197475#comment-13197475 ] Amos Feng commented on JBTM-2660: --------------------------------- the SPI one should try to be solved by making sure the SPI version we use doesn't expose in JTA 1.1 so that should be solved in that project. > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 01:16:03 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 01:16:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197486#comment-13197486 ] Amos Feng commented on JBTM-2660: --------------------------------- It looks like the jca spec 1.5 dependency JTA 1.1 {code} +- org.jboss:jboss-transaction-spi:jar:7.3.0.Final:provided [INFO] | \- org.jboss.spec.javax.resource:jboss-connector-api_1.5_spec:jar:1.0.0.Final:provided [INFO] | \- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:provided {code} > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 05:04:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 05:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197591#comment-13197591 ] Amos Feng commented on JBTM-2634: --------------------------------- It looks like it is in the spring-boot-1.4.0-M2 release now. > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 05:08:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 27 Apr 2016 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197596#comment-13197596 ] Tom Jenkinson commented on JBTM-2660: ------------------------------------- Good work Amos, I wonder if we can upgrade the SPI org.jboss.spec.javax.resource:jboss-connector-api_1.5_spec:jar:1.0.0.Final dependency to a later one that includes JTA 1.2? > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 21:16:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 21:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198124#comment-13198124 ] Amos Feng commented on JBTM-2660: --------------------------------- yeah, it looks like we need to upgrade to jboss-connector-api_1.7_spec:1.0.0.Final which includes JTA 1.2 > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 21:19:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 21:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2663) Upgrade to jboss-connector-api_1.7_spec 1.0.0.Final in jboss-transaction-spi In-Reply-To: References: Message-ID: Amos Feng created JBTM-2663: ------------------------------- Summary: Upgrade to jboss-connector-api_1.7_spec 1.0.0.Final in jboss-transaction-spi Key: JBTM-2663 URL: https://issues.jboss.org/browse/JBTM-2663 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next It includes the JTA 1.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 21:27:00 2016 From: issues at jboss.org (Anonymous (JIRA)) Date: Wed, 27 Apr 2016 21:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2663) Upgrade to jboss-connector-api_1.7_spec 1.0.0.Final in jboss-transaction-spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #8 in GitHub ------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade to jboss-connector-api_1.7_spec 1.0.0.Final in jboss-transaction-spi > ---------------------------------------------------------------------------- > > Key: JBTM-2663 > URL: https://issues.jboss.org/browse/JBTM-2663 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > It includes the JTA 1.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 21:29:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 21:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198127#comment-13198127 ] Amos Feng commented on JBTM-2660: --------------------------------- It works with this upgrading > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Apr 27 23:13:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 27 Apr 2016 23:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198135#comment-13198135 ] Amos Feng commented on JBTM-2634: --------------------------------- It needs to add the spring milestone repository {code} spring-milestone Spring Milestone Repository https://repo.spring.io/milestone spring-milestone Spring Milestone Repository https://repo.spring.io/milestone {code} > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 29 05:55:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 29 Apr 2016 05:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2664) Create a PR job to test SPI changes (against Narayana master) In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2664: -------------------------------------- Summary: Create a PR job to test SPI changes (against Narayana master) Key: JBTM-2664 URL: https://issues.jboss.org/browse/JBTM-2664 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Affects Versions: 5.3.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove SPI changes should be tested against the current narayana master during github pull requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Apr 29 05:56:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 29 Apr 2016 05:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2664) Create a PR job to test SPI changes (against Narayana master) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2664: ----------------------------------- Affects Version/s: (was: 5.3.2.Final) > Create a PR job to test SPI changes (against Narayana master) > ------------------------------------------------------------- > > Key: JBTM-2664 > URL: https://issues.jboss.org/browse/JBTM-2664 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > SPI changes should be tested against the current narayana master during github pull requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)