From issues at jboss.org Mon Feb 4 04:15:03 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:15:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-1107: ---------------------------------- Status: Open (was: Pull Request Sent) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.later > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:16:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:16:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2976) Make jdbc connection pools separate per db url In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2976: ---------------------------------- Priority: Minor (was: Major) > Make jdbc connection pools separate per db url > ---------------------------------------------- > > Key: JBTM-2976 > URL: https://issues.jboss.org/browse/JBTM-2976 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > As follow-up to issue https://issues.jboss.org/browse/JBTM-2972 discussed at https://github.com/jbosstm/narayana/pull/1269#issuecomment-352737031: > when the Narayana pooling implementation is used then parameter `maxConnections` refers to all connections created by transactional driver. As an enhancement we should consider to count max connection pool per db url (aka. per datasource) not globally. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:16:02 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:16:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2976) Make jdbc connection pools separate per db url In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690528#comment-13690528 ] Ondra Chaloupka commented on JBTM-2976: --------------------------------------- the currently supported JDBC engine used for integration with Spring and Tomcat is DBCP2 > Make jdbc connection pools separate per db url > ---------------------------------------------- > > Key: JBTM-2976 > URL: https://issues.jboss.org/browse/JBTM-2976 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > As follow-up to issue https://issues.jboss.org/browse/JBTM-2972 discussed at https://github.com/jbosstm/narayana/pull/1269#issuecomment-352737031: > when the Narayana pooling implementation is used then parameter `maxConnections` refers to all connections created by transactional driver. As an enhancement we should consider to count max connection pool per db url (aka. per datasource) not globally. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:17:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:17:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2733: ---------------------------------- Priority: Minor (was: Major) > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:28:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2985) Make jdbc transaction driver dynamic properties file being loaded from classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka closed JBTM-2985. --------------------------------- Resolution: Won't Do As jdbc driver is not used as integration pooling this is probably not needed when it brings backward compatibility issue. Closing. In case if it's needed in future it could be reopened. > Make jdbc transaction driver dynamic properties file being loaded from classpath > -------------------------------------------------------------------------------- > > Key: JBTM-2985 > URL: https://issues.jboss.org/browse/JBTM-2985 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at https://developer.jboss.org/message/979661? > The fix is here > https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 > Info on using driver is here > https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:29:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:29:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3060) Enhance quickstart readme with summary of all quickstarts while sorting them into categories In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3060: ---------------------------------- Status: Open (was: Pull Request Sent) There is need to be more work on this task > Enhance quickstart readme with summary of all quickstarts while sorting them into categories > -------------------------------------------------------------------------------------------- > > Key: JBTM-3060 > URL: https://issues.jboss.org/browse/JBTM-3060 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The current README of the quickstart repository https://github.com/jbosstm/quickstart/blob/5.9.0.Final/README.md is a bit modest. Any stranger should get information about the overall structure of the repo while guiding him to find the quickstart he needs. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:29:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:29:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3060) Enhance quickstart readme with summary of all quickstarts while sorting them into categories In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690539#comment-13690539 ] Ondra Chaloupka edited comment on JBTM-3060 at 2/4/19 4:28 AM: --------------------------------------------------------------- There is need to be more work on this task => multiple PRs are needed was (Author: ochaloup): There is need to be more work on this task > Enhance quickstart readme with summary of all quickstarts while sorting them into categories > -------------------------------------------------------------------------------------------- > > Key: JBTM-3060 > URL: https://issues.jboss.org/browse/JBTM-3060 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The current README of the quickstart repository https://github.com/jbosstm/quickstart/blob/5.9.0.Final/README.md is a bit modest. Any stranger should get information about the overall structure of the repo while guiding him to find the quickstart he needs. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 4 04:32:03 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 4 Feb 2019 04:32:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3078) JDBC transaction driver does not support MSSQL, the list should be enriched In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3078: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.1.Final Resolution: Done > JDBC transaction driver does not support MSSQL, the list should be enriched > --------------------------------------------------------------------------- > > Key: JBTM-3078 > URL: https://issues.jboss.org/browse/JBTM-3078 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Affects Versions: 5.9.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.9.1.Final > > > The transactional jdbc driver does not support MSSQL driver. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 12 04:51:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Tue, 12 Feb 2019 04:51:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-3104: ----------------------------------- Summary: Define a separate CI profile for LRA Key: JBTM-3104 URL: https://issues.jboss.org/browse/JBTM-3104 Project: JBoss Transaction Manager Issue Type: Task Components: Build System, LRA Reporter: Tom Jenkinson Assignee: Michael Musgrove This could be similar to how the XTS and RTS profile is constructed. Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 12 04:53:05 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Tue, 12 Feb 2019 04:53:05 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3057) build javadoc failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-3057: ----------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > build javadoc failure > --------------------- > > Key: JBTM-3057 > URL: https://issues.jboss.org/browse/JBTM-3057 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Major > > I have to disable the maven-javadoc-plugin on the JDK9 and it needs more investigation. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 12 05:14:10 2019 From: issues at jboss.org (Amos Feng (Jira)) Date: Tue, 12 Feb 2019 05:14:10 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2495) Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed JBTM-2495. --------------------------- Release Notes Text: I think this could be marked with Out of Date since the blacktie is just test with Wildfly 10 now. Resolution: Out of Date > Installing Blacktie 5.2.2 with Wildfly 9.0.1.Final Fails: Docs needs to say use WFLY "master" (or appropriate) > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2495 > URL: https://issues.jboss.org/browse/JBTM-2495 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie, Documentation > Affects Versions: 5.0.0.M2 > Environment: RHEL 6.3 > Reporter: Joice Joy > Priority: Minor > > I am installing Blacktie 5.2.2 Final with Wildfly 9.0.1 but the Wildfly server fails to start the Blacktie service > But the server does not start the blacktie service: > This is from quickstart quickstart/blacktie > > > > ========================================================================= > > > JBoss Bootstrap Environment > > > JBOSS_HOME: /fxtest/trep/wildfly/wildfly-9.0.1.Final > > > JAVA: /fxtest/trep/java/jdk1.8.0_51/bin/java > > > JAVA_OPTS: -server -XX:+UseCompressedOops -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE > > > ========================================================================= > > > Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 > 07:35:52,490 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.3.Final > 07:35:52,892 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final > 07:35:53,007 INFO [org.jboss.as] (MSC service thread 1-3) WFLYSRV0049: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) starting > 07:35:55,053 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'job-repository-type' in the resource at address '/subsystem=batch' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,055 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 21) WFLYCTL0028: Attribute 'enabled' in the resource at address '/subsystem=datasources/data-source=ExampleDS' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation. > 07:35:55,121 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment blacktie-admin-services-ear-5.2.2.Final.ear > 07:35:55,361 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 24) WFLYDR0001: Content added at location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:55,390 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > 07:35:55,422 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.3.1.Final > 07:35:55,438 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.3.1.Final > 07:35:55,482 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.9.Final > 07:35:55,548 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 41) WFLYCLINF0001: Activating Infinispan subsystem. > 07:35:55,554 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 40) WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors > 07:35:55,557 INFO [org.wildfly.iiop.openjdk] (ServerService Thread Pool -- 42) WFLYIIOP0001: Activating IIOP Subsystem > 07:35:55,602 INFO [org.jboss.as.connector] (MSC service thread 1-1) WFLYJCA0009: Starting JCA Subsystem (IronJacamar 1.2.4.Final) > 07:35:55,615 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 48) WFLYJSF0007: Activated the following JSF Implementations: [main] > 07:35:55,652 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0004: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) > 07:35:55,661 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 52) WFLYNAM0001: Activating Naming Subsystem > 07:35:55,670 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0018: Started Driver service with driver-name = h2 > 07:35:55,827 INFO [org.jboss.as.security] (ServerService Thread Pool -- 59) WFLYSEC0002: Activating Security Subsystem > 07:35:55,829 INFO [org.jboss.as.security] (MSC service thread 1-4) WFLYSEC0001: Current PicketBox version=4.9.2.Final > 07:35:55,849 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique. > 07:35:55,849 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 62) WFLYWS0002: Activating WebServices Extension > 07:35:55,998 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,034 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.2.9.Final starting > 07:35:56,095 INFO [org.jboss.as.naming] (MSC service thread 1-2) WFLYNAM0003: Starting Naming Service > 07:35:56,119 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0001: Bound mail session [java:jboss/mail/Default] > 07:35:56,352 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0014: Creating file handler for path /fxtest/trep/wildfly/wildfly-9.0.1.Final/welcome-content > 07:35:56,417 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server. > 07:35:56,437 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0018: Host default-host starting > 07:35:56,589 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8080 > 07:35:56,945 INFO [org.wildfly.iiop.openjdk] (MSC service thread 1-3) WFLYIIOP0009: CORBA ORB Service started > 07:35:56,969 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS] > 07:35:57,030 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-3) WFLYDS0013: Started FileSystemDeploymentService for directory /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/deployments > 07:35:57,059 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:57,187 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingjournal,bindingsDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingbindings,largeMessagesDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messaginglargemessages,pagingDirectory=/fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/messagingpaging) > 07:35:57,193 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221006: Waiting to obtain live lock > 07:35:57,287 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221012: Using AIO Journal > 07:35:57,387 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support CORE > 07:35:57,414 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Final > 07:35:57,439 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support AMQP > 07:35:57,443 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221043: Adding protocol support STOMP > 07:35:57,502 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221034: Waiting to obtain live lock > 07:35:57,504 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221035: Live Server Obtained live lock > 07:35:58,108 INFO [org.jboss.messaging] (MSC service thread 1-3) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor > 07:35:58,112 INFO [org.jboss.messaging] (MSC service thread 1-1) WFLYMSG0016: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor > 07:35:58,206 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221007: Server is now live > 07:35:58,207 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221001: HornetQ Server version 2.4.7.Final (2.4.7.Final, 124) [9d12c6a3-4666-11e5-8632-95a54ac84561] > 07:35:58,210 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 64) HQ221003: trying to deploy queue jms.queue.ExpiryQueue > 07:35:58,514 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 66) WFLYMSG0002: Bound messaging object to jndi name java:/ConnectionFactory > 07:35:58,519 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 67) WFLYMSG0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory > 07:35:58,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 65) HQ221003: trying to deploy queue jms.queue.DLQ > 07:35:58,623 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0007: Registered connection factory java:/JmsXA > 07:35:58,721 INFO [org.hornetq.ra] (MSC service thread 1-4) HornetQ resource adaptor started > 07:35:58,721 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-4) IJ020002: Deployed: file://RaActivatorhornetq-ra > 07:35:58,733 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-4) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA] > 07:35:58,733 INFO [org.jboss.as.messaging] (MSC service thread 1-4) WFLYMSG0002: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jaxb-impl.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,762 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry jsr173_1.0_api.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,763 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry activation.jar in /content/blacktie-admin-services-ear-5.2.2.Final.ear/lib/jaxb-xjc-2.0EA3.jar does not point to a valid jar for a Class-Path reference. > 07:35:58,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0207: Starting subdeployment (runtime-name: "blacktie-admin-services-5.2.2.Final.jar") > 07:35:58,885 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:98) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:95) > ... 6 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment' > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.jboss.as.messaging.deployment.MessagingXmlParsingDeploymentUnitProcessor.deploy(MessagingXmlParsingDeploymentUnitProcessor.java:89) > ... 6 more > > > 07:35:58,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "blacktie-admin-services-ear-5.2.2.Final.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"blacktie-admin-services-ear-5.2.2.Final.ear\".\"blacktie-admin-services-5.2.2.Final.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"blacktie-admin-services-5.2.2.Final.jar\" of deployment \"blacktie-admin-services-ear-5.2.2.Final.ear\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSG0055: Could not parse file /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/tmp/vfs/deployment/deployment865003eadac08a4f/blacktie-admin-services-5.2.2.Final.jar-9cb8aa19a9dae2ff/contents/META-INF/activemq-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,1] > Message: Unexpected element '{urn:jboss:messaging-activemq-deployment:1.0}messaging-deployment'"}} > 07:35:58,980 INFO [org.jboss.as.server] (ServerService Thread Pool -- 37) WFLYSRV0010: Deployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name : "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:58,982 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "blacktie-admin-services-5.2.2.Final.jar" of deployment "blacktie-admin-services-ear-5.2.2.Final.ear" > > > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management > 07:35:59,202 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 > 07:35:59,202 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 7156ms - Started 247 of 423 services (2 services failed or missing dependencies, 222 services are lazy, passive or on-demand) > 07:35:59,243 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0208: Stopped subdeployment (runtime-name: blacktie-admin-services-5.2.2.Final.jar) in 9ms > 07:35:59,332 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment blacktie-admin-services-ear-5.2.2.Final.ear (runtime-name: blacktie-admin-services-ear-5.2.2.Final.ear) in 98ms > 07:35:59,413 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /fxtest/trep/wildfly/wildfly-9.0.1.Final/standalone/data/content/6a/4973c6ad23d3978c57f955fd341a56f1bc550a/content > 07:35:59,414 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "blacktie-admin-services-ear-5.2.2.Final.ear" (runtime-name: "blacktie-admin-services-ear-5.2.2.Final.ear") > 07:35:59,414 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."blacktie-admin-services-ear-5.2.2.Final.ear"."blacktie-admin-services-5.2.2.Final.jar".PARSE -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 12 12:15:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 12 Feb 2019 12:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694520#comment-13694520 ] Michael Musgrove commented on JBTM-3104: ---------------------------------------- The XTS and RTS profiles are for testing with WildFly whereas LRA is a standard module. The tests for LRA are just standard module tests and we do not use profiles to disable tests. Also profiles were introduced to speed up PR testing and the LRA module does not take long to run. The current issue with code coverage tests failing on LRA arose because I accidentally reverted my fix to disable the site plugin (JBTM-3093). I have just raised [PR 1404|https://github.com/jbosstm/narayana/pull/1404] to disable the site plugin for LRA. > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 12 12:16:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Tue, 12 Feb 2019 12:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3104) Define a separate CI profile for LRA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694520#comment-13694520 ] Michael Musgrove edited comment on JBTM-3104 at 2/12/19 12:15 PM: ------------------------------------------------------------------ The XTS and RTS profiles are for testing with WildFly whereas LRA is a standard module. The tests for LRA are just standard module tests and we do not use profiles to disable tests. Also profiles were introduced to speed up PR testing and the LRA module does not take long to run. The current issue with code coverage tests failing on LRA arose because I accidentally reverted my fix to disable the site plugin (JBTM-3093). I have just raised [PR 1404|https://github.com/jbosstm/narayana/pull/1404] to disable the site plugin for LRA. [~tomjenkinson] do you mind if I close this as will not fix? was (Author: mmusgrov): The XTS and RTS profiles are for testing with WildFly whereas LRA is a standard module. The tests for LRA are just standard module tests and we do not use profiles to disable tests. Also profiles were introduced to speed up PR testing and the LRA module does not take long to run. The current issue with code coverage tests failing on LRA arose because I accidentally reverted my fix to disable the site plugin (JBTM-3093). I have just raised [PR 1404|https://github.com/jbosstm/narayana/pull/1404] to disable the site plugin for LRA. > Define a separate CI profile for LRA > ------------------------------------ > > Key: JBTM-3104 > URL: https://issues.jboss.org/browse/JBTM-3104 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Major > > This could be similar to how the XTS and RTS profile is constructed. > Changes are anticipated in the narayana.sh, maybe pom IDK, and the pull job and main job -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 04:25:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 13 Feb 2019 04:25:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3105) STM TaxonomyTest failure In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3105: -------------------------------------- Summary: STM TaxonomyTest failure Key: JBTM-3105 URL: https://issues.jboss.org/browse/JBTM-3105 Project: JBoss Transaction Manager Issue Type: Bug Components: STM Affects Versions: 5.9.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next There was test failure during a CI PR test: testIsClosedNestedParentNotVisible(org.jboss.stm.TaxonomyTest) on job http://narayanaci1.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/jdk=jdk9.latest,label=catelyn/12/ -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 07:17:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 07:17:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3106) Firing an @Initialized(TransactionScoped.class) event In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3106: ------------------------------------- Summary: Firing an @Initialized(TransactionScoped.class) event Key: JBTM-3106 URL: https://issues.jboss.org/browse/JBTM-3106 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Affects Versions: 5.9.2.Final Reporter: Ondra Chaloupka Assignee: Laird Nelson It would be beneficial to have the CDI-specific wrapper around Narayana's TransactionManagerImple that fires an @Initialized(TransactionScoped.class)-qualified event. For the CDI, it's a good practice. The all built-in scopes have to provide this behaviour. The CDI specification says (in section 6.7): {quote} Portable extensions are encouraged to synchronously fire: * an event with qualifier @Initialized(X.class) when a custom context is initialized, i.e. ready for use, * an event with qualifier @BeforeDestroyed(X.class) when a custom context is about to be destroyed, i.e. before the actual destruction, * an event with qualifier @Destroyed(X.class) when a custom context is destroyed, i.e. after the actual destruction, where X is the scope type associated with the context. A suitable event payload should be chosen. {quote} The {{begin()}} method a Narayana-supplied but CDI-specific transaction manager wrapping Narayana's "ordinary" one should do: {code} @Inject @Initialized(TransactionScoped.class) private Event initializationBroadcaster; @Inject @BeforeDestroyed(TransactionScoped.class) private Event beforeDestructionBroadcaster; @Inject @Destroyed(TransactionScoped.class) private Event destructionBroadcaster; // in its begin() method: super.begin(); initializationBroadcaster.fire(this.getTransaction()); // in its commit() and rollback() methods and anywhere else I'm forgetting: beforeDestructionBroadcaster.fire(this.getTransaction()); super.commit(); // or rollback or whatever destructionBroadcaster.fire(this); {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 07:17:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 07:17:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3106) Firing an @Initialized(TransactionScoped.class) event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3106: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1403 > Firing an @Initialized(TransactionScoped.class) event > ----------------------------------------------------- > > Key: JBTM-3106 > URL: https://issues.jboss.org/browse/JBTM-3106 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Laird Nelson > Priority: Major > > It would be beneficial to have the CDI-specific wrapper around Narayana's TransactionManagerImple that fires an @Initialized(TransactionScoped.class)-qualified event. > For the CDI, it's a good practice. The all built-in scopes have to provide this behaviour. > > The CDI specification says (in section 6.7): > {quote} > Portable extensions are encouraged to synchronously fire: > * an event with qualifier @Initialized(X.class) when a custom context is initialized, i.e. ready for use, > * an event with qualifier @BeforeDestroyed(X.class) when a custom context is about to be destroyed, i.e. before the actual destruction, > * an event with qualifier @Destroyed(X.class) when a custom context is destroyed, i.e. after the actual destruction, > where X is the scope type associated with the context. > A suitable event payload should be chosen. > {quote} > > The {{begin()}} method a Narayana-supplied but CDI-specific transaction manager wrapping Narayana's "ordinary" one should do: > {code} > @Inject > @Initialized(TransactionScoped.class) > private Event initializationBroadcaster; > @Inject @BeforeDestroyed(TransactionScoped.class) > private Event beforeDestructionBroadcaster; > @Inject @Destroyed(TransactionScoped.class) > private Event destructionBroadcaster; > // in its begin() method: > super.begin(); > initializationBroadcaster.fire(this.getTransaction()); > // in its commit() and rollback() methods and anywhere else I'm forgetting: > beforeDestructionBroadcaster.fire(this.getTransaction()); > super.commit(); // or rollback or whatever > destructionBroadcaster.fire(this); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 12:40:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 12:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages misses information from parameters In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3107: ------------------------------------- Summary: Some of the logging messages misses information from parameters Key: JBTM-3107 URL: https://issues.jboss.org/browse/JBTM-3107 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.9.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. {code} ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} {code} The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected to not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 13:02:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 13:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3107: ---------------------------------- Summary: Some of the logging messages miss parameter's values to be printed (was: Some of the logging messages misses information from parameters) > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected to not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 13:02:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 13:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1406 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected to not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 13 15:19:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 13 Feb 2019 15:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3107: ---------------------------------- Description: Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. {code} ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} {code} The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. was: Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. {code} ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} {code} The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected to not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 14 05:04:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Thu, 14 Feb 2019 05:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3108) Renable the maven site plugin for the LRA module In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3108: -------------------------------------- Summary: Renable the maven site plugin for the LRA module Key: JBTM-3108 URL: https://issues.jboss.org/browse/JBTM-3108 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later Issue https://issues.jboss.org/browse/JBTM-3093 disabled the site plugin while the MP LRA APIs are still being developed. When MP LRA releases we need to renable the site plugin (used for code coverage tests). -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 14 07:52:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Feb 2019 07:52:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3109: ------------------------------------- Summary: Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec Key: JBTM-3109 URL: https://issues.jboss.org/browse/JBTM-3109 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.9.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 14 07:57:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 14 Feb 2019 07:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1408 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 10:13:00 2019 From: issues at jboss.org (Cody Lerum (Jira)) Date: Fri, 15 Feb 2019 10:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: Cody Lerum created JBTM-3110: -------------------------------- Summary: JNDIBean CDI Deployment Failure Key: JBTM-3110 URL: https://issues.jboss.org/browse/JBTM-3110 Project: JBoss Transaction Manager Issue Type: Bug Environment: Wildfly 16 Beta 1 Reporter: Cody Lerum Fix For: 5.9.1.Final While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. {code} org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485) {code} I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 10:29:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 15 Feb 2019 10:29:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3111: ------------------------------------- Summary: Periodic recovery thread and thread terminating transaction manager can deadlock Key: JBTM-3111 URL: https://issues.jboss.org/browse/JBTM-3111 Project: JBoss Transaction Manager Issue Type: Bug Components: Recovery Affects Versions: 5.9.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. When looking to WFLY-10841 the thread dump talks about {code} "Periodic Recovery": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) "ServerService Thread Pool -- 8": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485) {code} We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 10:30:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 15 Feb 2019 10:30:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3111: ---------------------------------- Description: The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. When looking to WFLY-11706 the thread dump talks about {code} "Periodic Recovery": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) "ServerService Thread Pool -- 8": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485) {code} We need to avaoid this dead lock. was: The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. When looking to WFLY-10841 the thread dump talks about {code} "Periodic Recovery": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) "ServerService Thread Pool -- 8": at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485) {code} We need to avaoid this dead lock. > Periodic recovery thread and thread terminating transaction manager can deadlock > -------------------------------------------------------------------------------- > > Key: JBTM-3111 > URL: https://issues.jboss.org/browse/JBTM-3111 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. > When looking to WFLY-11706 the thread dump talks about > {code} > "Periodic Recovery": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) > - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) > - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > "ServerService Thread Pool -- 8": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) > - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) > - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 10:38:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 15 Feb 2019 10:38:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1409 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Periodic recovery thread and thread terminating transaction manager can deadlock > -------------------------------------------------------------------------------- > > Key: JBTM-3111 > URL: https://issues.jboss.org/browse/JBTM-3111 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. > When looking to WFLY-11706 the thread dump talks about > {code} > "Periodic Recovery": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) > - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) > - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > "ServerService Thread Pool -- 8": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) > - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) > - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 10:51:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Fri, 15 Feb 2019 10:51:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3107: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 11:46:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Fri, 15 Feb 2019 11:46:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-3110: ----------------------------------- Assignee: Ondra Chaloupka > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 15 11:48:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Fri, 15 Feb 2019 11:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696142#comment-13696142 ] Tom Jenkinson commented on JBTM-3110: ------------------------------------- [~ochaloup] - may I request you to take a look at this one please? I think it is related to https://github.com/jbosstm/narayana/pull/1346 > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Sun Feb 17 16:11:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Sun, 17 Feb 2019 16:11:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696321#comment-13696321 ] Ondra Chaloupka commented on JBTM-3110: --------------------------------------- [~tomjenkinson] yes. The reason is based on the changes at JBTM-3044. I think we need the fix (https://github.com/manovotn/narayana/tree/wfly11716) that was proposed by [~manovotn]. I will check with him. > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 18 02:56:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Mon, 18 Feb 2019 02:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3112) Remove dependency on LRA client from LRA coordinator In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3112: ------------------------------------- Summary: Remove dependency on LRA client from LRA coordinator Key: JBTM-3112 URL: https://issues.jboss.org/browse/JBTM-3112 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.9.2.Final Reporter: Martin Stefanko Assignee: Martin Stefanko LRA coordinator should not depend on LRA client as these services should be able to operate independently (as separate microservices deployments). -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 18 04:06:14 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 18 Feb 2019 04:06:14 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-3110: ------------------------------------- Assignee: Matej Novotny (was: Ondra Chaloupka) > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 18 04:07:03 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Mon, 18 Feb 2019 04:07:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696425#comment-13696425 ] Ondra Chaloupka commented on JBTM-3110: --------------------------------------- I'm assigning to [~manovotn] as he works on the fix. > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 18 04:58:17 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Mon, 18 Feb 2019 04:58:17 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Matej Novotny created pull request #1410 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Feb 18 04:58:18 2019 From: issues at jboss.org (Matej Novotny (Jira)) Date: Mon, 18 Feb 2019 04:58:18 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Novotny updated JBTM-3110: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1410 > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 19 06:16:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Tue, 19 Feb 2019 06:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3110: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.1.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Tue Feb 19 06:41:00 2019 From: issues at jboss.org (Anonymous (Jira)) Date: Tue, 19 Feb 2019 06:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3112) Remove dependency on LRA client from LRA coordinator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Martin Stefanko created pull request #1412 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Remove dependency on LRA client from LRA coordinator > ---------------------------------------------------- > > Key: JBTM-3112 > URL: https://issues.jboss.org/browse/JBTM-3112 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > LRA coordinator should not depend on LRA client as these services should be able to operate independently (as separate microservices deployments). -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 20 05:04:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 20 Feb 2019 05:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3113) LRA coordinator defines in depenedencies whole microprofile stack In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3113: ------------------------------------- Summary: LRA coordinator defines in depenedencies whole microprofile stack Key: JBTM-3113 URL: https://issues.jboss.org/browse/JBTM-3113 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The LRA coordinator defines the depenendency on whole MicroProfile stack. That's not necessary as it uses JAX-RS and CDI. The depenencies needed up to that will be resolved by the Wfly Swarm/Thorntail runtime. If we define whole stack then Wfly Swarm loads to the runtime unnecessary dependencies which makes the fat jar bigger than it needs to be. Plus the start time the container could be lower when we use only the dependencies which are really needed. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 20 05:05:01 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Wed, 20 Feb 2019 05:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3113) LRA coordinator defines in depenedencies whole microprofile stack In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3113: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1408 > LRA coordinator defines in depenedencies whole microprofile stack > ----------------------------------------------------------------- > > Key: JBTM-3113 > URL: https://issues.jboss.org/browse/JBTM-3113 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The LRA coordinator defines the depenendency on whole MicroProfile stack. That's not necessary as it uses JAX-RS and CDI. The depenencies needed up to that will be resolved by the Wfly Swarm/Thorntail runtime. If we define whole stack then Wfly Swarm loads to the runtime unnecessary dependencies which makes the fat jar bigger than it needs to be. Plus the start time the container could be lower when we use only the dependencies which are really needed. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3091) LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3091. ------------------------------- > LRA module should depend on a specific snapshot build > ----------------------------------------------------- > > Key: JBTM-3091 > URL: https://issues.jboss.org/browse/JBTM-3091 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > The current implementation was coded against the following maven snapshot: > org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20181217.132756-202 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3105) STM TaxonomyTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3105: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > STM TaxonomyTest failure > ------------------------ > > Key: JBTM-3105 > URL: https://issues.jboss.org/browse/JBTM-3105 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > There was test failure during a CI PR test: testIsClosedNestedParentNotVisible(org.jboss.stm.TaxonomyTest) on job > http://narayanaci1.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/jdk=jdk9.latest,label=catelyn/12/ -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3093) Disable the maven site plugin for the LRA module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3093: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Disable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3093 > URL: https://issues.jboss.org/browse/JBTM-3093 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The narayana code coverage profile invokes the maven site goal so that the output can be viewed easily. > > Now LRA relies on microprofile-lra-api snapshot builds but the site plugin appears to resolve to the latest snapshot (rather than a particular snapshot build) and since microprofile-lra-api regularly undergoes changes there are compilation failures. > This JIRA proposes that we disable the site plugin for the LRA module. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3090) LRA TCK failures need to report more context to facilitate debugging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3090: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > LRA TCK failures need to report more context to facilitate debugging > -------------------------------------------------------------------- > > Key: JBTM-3090 > URL: https://issues.jboss.org/browse/JBTM-3090 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test failure message reports > > failures.forEach(f -> System.out.printf("%s%n", f)); > where f is the failure reason. There is also a verbose option which prints out the stack trace where the failure was reported. But in some failure cases these two pieces of information are insufficient to debug the failure. It would be nice if the resources that participated in the test also logged information which could be reported for more effective analysis of the reasons for the failure. This last requirement may affect the TCK itself so the code in the eclipse microprofile-lra repo should be analysed as well. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3089) LRA code improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3089: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > LRA code improvements > --------------------- > > Key: JBTM-3089 > URL: https://issues.jboss.org/browse/JBTM-3089 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Remove TODO comments from the code and replace with JIRA issues. > Ensure that the message string in all occurrences of GenericLRAException are meaningful. > Remove all commented out pieces of code. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3087) Ensure the LRA implementation is up to date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3087: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Ensure the LRA implementation is up to date > ------------------------------------------- > > Key: JBTM-3087 > URL: https://issues.jboss.org/browse/JBTM-3087 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3086) dependentLRA test failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3086: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > dependentLRA test failure > ------------------------- > > Key: JBTM-3086 > URL: https://issues.jboss.org/browse/JBTM-3086 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java/org/eclipse/microprofile/lra/tck/TckTests.java#L461] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/src/main/java/org/eclipse/microprofile/lra/annotation/LRA.java#L176] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3073) Do not mandate JAX-RS annotations on @Compensate/@Complete methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3073: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Do not mandate JAX-RS annotations on @Compensate/@Complete methods > ------------------------------------------------------------------ > > Key: JBTM-3073 > URL: https://issues.jboss.org/browse/JBTM-3073 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Cloned from [https://github.com/eclipse/microprofile-lra/issues/35|http://example.com]: > It is up to the implementation on how the Compensate methods are called. > This could be through JAX-RS calls but this should not be the only way (although an implementation will probably only implement one method). This makes it easier to use the 'events' way of coordination. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3072) Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3072: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose > ---------------------------------------------------------------------------------------- > > Key: JBTM-3072 > URL: https://issues.jboss.org/browse/JBTM-3072 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Add a test that verifies the correct behaviour when a method is annotated with both REQUIRES_NEW and delayClose, ie something like: > {code} > @PUT > @Path(ActivityController.ACCEPT_WORK) > @LRA(value = LRA.Type.REQUIRES_NEW, delayClose = true) > public Response doInNewLRA( ....) {...} > {code} > The expected behaviour is: > {code} > /** > * If called outside a LRA context a new LRA will be created for the > * the duration of the method call and when the call completes it will > * be closed (this behaviour can be overridden using the > * {@link LRA#delayClose} attribute). > * > * If called inside a LRA context it will be suspended and a new LRA > * context will be created for the duration of the call. When the method > * finishes this new LRA will be closed and the original context will be > * resumed. This behaviour can be overridden using the > * {@link LRA#delayClose} attribute) in which case the original LRA > * remains suspended and the new LRA becomes the active one and only > * when that one is terminated will the original context be resumed. > */ > REQUIRES_NEW, > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3071) Windows automation of the LRA examples quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3071: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Windows automation of the LRA examples quickstarts > -------------------------------------------------- > > Key: JBTM-3071 > URL: https://issues.jboss.org/browse/JBTM-3071 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA examples quickstarts (https://issues.jboss.org/browse/JBTM-3063) contain a bash script to run the examples. We need the equivalent for running on Windows. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3065: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Check that starting LRA's via CDI and API in the same method works > ------------------------------------------------------------------ > > Key: JBTM-3065 > URL: https://issues.jboss.org/browse/JBTM-3065 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation. > If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's. > The following code shows an example: > {code} > @PUT > @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry > public String doInTransaction() { > URL lraId = lraClient.startLRA(...); // starts a nested LRA > lraClient.join(...) // join the nested LRA > lraClient.closeLRA(lraId); // close the nested LRA > // assert that the nested callbacks were invoked > // assert that the callbacks for the outer LRA have not been called yet > } > {code} > Similar comments apply if the resource joins via the LRAManagement API: > {code} > @Inject > private LRAManagement lraManagement; > public String doInTransaction() { > lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS); > // etc > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3062) Include a test for LRA context propagation across a "non-LRA aware" service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3062: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Include a test for LRA context propagation across a "non-LRA aware" service > --------------------------------------------------------------------------- > > Key: JBTM-3062 > URL: https://issues.jboss.org/browse/JBTM-3062 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and service A in turn calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. A test is needed for this behaviour. > This issue relates to https://github.com/eclipse/microprofile-lra/issues/7 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3058) Add STM tests that verify nested transactions are closed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3058: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Add STM tests that verify nested transactions are closed > -------------------------------------------------------- > > Key: JBTM-3058 > URL: https://issues.jboss.org/browse/JBTM-3058 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > STM implements "Closed Nested Transactions" as opposed to Flattened or Open. We need a test which demonstrates that nested transactions follow the closed model. > Furthermore, STM implementations can differ in how transactional code and non-transactional code are isolated from each other (with respect to visibility of updates during a transaction). Add a test that verifies that we use the "Weak Isolation" model. > Details of the expected behaviour is covered in the Sept 2018 jbossts blog entitled "[Tips on how to evaluate STM implementations|http://example.com|https://jbossts.blogspot.com/2018/09/tips-on-how-to-evaluate-stm.html]" -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3051) LRA test timeLimit failure on JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3051: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > LRA test timeLimit failure on JDK 9 > ----------------------------------- > > Key: JBTM-3051 > URL: https://issues.jboss.org/browse/JBTM-3051 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Whilst fixing issue JBTM-2942 I noticed that the test timeLimitRequiredLRA fails consistently with the reason: > {quote} > 2018-08-14 11:38:00,244 INFO [stdout] (pool-7-thread-1) testName.getMethodName(): WARNING: test did not close http://localhost:8080/lra-coordinator/0_ffff0a3f00d6_245c07ef_5b72b0d1_104 > {quote} > I have temporarily disabled the test in the TCK runner: > {quote} > rts/lra/lra-tck/tck/src/main/java/org/eclipse/microprofile/lra/tck/RunTck.java > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3046: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3042: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > API to get detailed LRA information should not include stats type data > ---------------------------------------------------------------------- > > Key: JBTM-3042 > URL: https://issues.jboss.org/browse/JBTM-3042 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/main/java/io/narayana/lra/client/LRAInfoImpl.java#L90 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3020: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2968: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Some JTS quickstarts run with JacORB > ------------------------------------ > > Key: JBTM-2968 > URL: https://issues.jboss.org/browse/JBTM-2968 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are: > ArjunaJTS/pom.xml > ArjunaJTS/standalone/pom.xml > ArjunaJTS/trailmap/pom.xml -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3019) Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3019: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3019 > URL: https://issues.jboss.org/browse/JBTM-3019 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.8.1.Final > Environment: Docker enabled Jenkins slaves > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Minor > Fix For: 5.next > > > h3. Problem > The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images: > {code} > [root at karm-centos7-x86-64 ~]# docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > docker.io/postgres 9.4 26bd9b04b948 6 days ago 232 MB > docker.io/postgres 10 0965cdc98045 6 days ago 234 MB > docker.io/postgres ed5db6e669ff 7 weeks ago 263 MB > docker.io/postgres 30121e967865 7 weeks ago 289 MB > [root at karm-centos7-x86-64 ~]# docker ps -a > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > [root at karm-centos7-x86-64 ~]# > {code} > Although it leaves stray container volumes for some reason: > {code} > [root at karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes > 15G /var/lib/docker-latest/volumes > [root at karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l > 409 > {code} > It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway. > h3. Call to action > Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/src/main/java/io/narayana/db/PostgreContainerAllocator.java#L264] is supposed to be enough to not only remove the container but to also remove its volume. > h3. Workaround > {code} > docker volume prune > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2967: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2912: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Tom Jenkinson > Priority: Major > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:07:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:07:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Major > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:09:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3110: -------------------------------- Fix Version/s: 5.9.3.Final (was: 5.9.1.Final) > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.3.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:10:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3111: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Periodic recovery thread and thread terminating transaction manager can deadlock > -------------------------------------------------------------------------------- > > Key: JBTM-3111 > URL: https://issues.jboss.org/browse/JBTM-3111 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > Fix For: 5.9.3.Final > > > The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. > When looking to WFLY-11706 the thread dump talks about > {code} > "Periodic Recovery": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) > - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) > - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > "ServerService Thread Pool -- 8": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) > - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) > - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:11:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:11:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3109: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:12:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:12:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3113) LRA coordinator defines in depenedencies whole microprofile stack In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3113: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > LRA coordinator defines in depenedencies whole microprofile stack > ----------------------------------------------------------------- > > Key: JBTM-3113 > URL: https://issues.jboss.org/browse/JBTM-3113 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.9.3.Final > > > The LRA coordinator defines the depenendency on whole MicroProfile stack. That's not necessary as it uses JAX-RS and CDI. The depenencies needed up to that will be resolved by the Wfly Swarm/Thorntail runtime. If we define whole stack then Wfly Swarm loads to the runtime unnecessary dependencies which makes the fat jar bigger than it needs to be. Plus the start time the container could be lower when we use only the dependencies which are really needed. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:12:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:12:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3067) Build and run the narayana with JDK-11 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3067: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Build and run the narayana with JDK-11 > -------------------------------------- > > Key: JBTM-3067 > URL: https://issues.jboss.org/browse/JBTM-3067 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.9.3.Final > > > The jdk-11 could be downloaded from https://jdk.java.net/11/ and the most important feature that impacts us is [JEP 320: Remove the Java EE and CORBA Modules|https://openjdk.java.net/jeps/320] > The CI job is http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-11/ -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:13:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3107: -------------------------------- Fix Version/s: 5.9.3.Final > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:13:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3093) Disable the maven site plugin for the LRA module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3093: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final (was: 5.next) Resolution: Done > Disable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3093 > URL: https://issues.jboss.org/browse/JBTM-3093 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The narayana code coverage profile invokes the maven site goal so that the output can be viewed easily. > > Now LRA relies on microprofile-lra-api snapshot builds but the site plugin appears to resolve to the latest snapshot (rather than a particular snapshot build) and since microprofile-lra-api regularly undergoes changes there are compilation failures. > This JIRA proposes that we disable the site plugin for the LRA module. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:14:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:14:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3087) Ensure the LRA implementation is up to date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3087: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final (was: 5.next) Resolution: Done > Ensure the LRA implementation is up to date > ------------------------------------------- > > Key: JBTM-3087 > URL: https://issues.jboss.org/browse/JBTM-3087 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3113) LRA coordinator defines in depenedencies whole microprofile stack In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3113. ------------------------------- > LRA coordinator defines in depenedencies whole microprofile stack > ----------------------------------------------------------------- > > Key: JBTM-3113 > URL: https://issues.jboss.org/browse/JBTM-3113 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.9.3.Final > > > The LRA coordinator defines the depenendency on whole MicroProfile stack. That's not necessary as it uses JAX-RS and CDI. The depenencies needed up to that will be resolved by the Wfly Swarm/Thorntail runtime. If we define whole stack then Wfly Swarm loads to the runtime unnecessary dependencies which makes the fat jar bigger than it needs to be. Plus the start time the container could be lower when we use only the dependencies which are really needed. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3067) Build and run the narayana with JDK-11 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3067. ------------------------------- > Build and run the narayana with JDK-11 > -------------------------------------- > > Key: JBTM-3067 > URL: https://issues.jboss.org/browse/JBTM-3067 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.9.3.Final > > > The jdk-11 could be downloaded from https://jdk.java.net/11/ and the most important feature that impacts us is [JEP 320: Remove the Java EE and CORBA Modules|https://openjdk.java.net/jeps/320] > The CI job is http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-11/ -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3111. ------------------------------- > Periodic recovery thread and thread terminating transaction manager can deadlock > -------------------------------------------------------------------------------- > > Key: JBTM-3111 > URL: https://issues.jboss.org/browse/JBTM-3111 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > Fix For: 5.9.3.Final > > > The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. > When looking to WFLY-11706 the thread dump talks about > {code} > "Periodic Recovery": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) > - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) > - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > "ServerService Thread Pool -- 8": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) > - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) > - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3107. ------------------------------- > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3109. ------------------------------- > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3087) Ensure the LRA implementation is up to date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3087. ------------------------------- > Ensure the LRA implementation is up to date > ------------------------------------------- > > Key: JBTM-3087 > URL: https://issues.jboss.org/browse/JBTM-3087 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:01 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3110. ------------------------------- > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.3.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean at 12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3093) Disable the maven site plugin for the LRA module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3093. ------------------------------- > Disable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3093 > URL: https://issues.jboss.org/browse/JBTM-3093 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The narayana code coverage profile invokes the maven site goal so that the output can be viewed easily. > > Now LRA relies on microprofile-lra-api snapshot builds but the site plugin appears to resolve to the latest snapshot (rather than a particular snapshot build) and since microprofile-lra-api regularly undergoes changes there are compilation failures. > This JIRA proposes that we disable the site plugin for the LRA module. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-3109: --------------------------------- > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3109: -------------------------------- Issue Type: Task (was: Enhancement) > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 06:15:02 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Thu, 21 Feb 2019 06:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3109. ------------------------------- Resolution: Done > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 21 07:37:00 2019 From: issues at jboss.org (Ondra Chaloupka (Jira)) Date: Thu, 21 Feb 2019 07:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3090) LRA TCK failures need to report more context to facilitate debugging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698715#comment-13698715 ] Ondra Chaloupka commented on JBTM-3090: --------------------------------------- [~mmusgrov] is this issue still relevant? I expect there could not enough information in the LRA TCK tests but just after refactoring it behaves a bit differently. So I'm just asking if this JIRA is not for to be reconsidered. > LRA TCK failures need to report more context to facilitate debugging > -------------------------------------------------------------------- > > Key: JBTM-3090 > URL: https://issues.jboss.org/browse/JBTM-3090 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test failure message reports > > failures.forEach(f -> System.out.printf("%s%n", f)); > where f is the failure reason. There is also a verbose option which prints out the stack trace where the failure was reported. But in some failure cases these two pieces of information are insufficient to debug the failure. It would be nice if the resources that participated in the test also logged information which could be reported for more effective analysis of the reasons for the failure. This last requirement may affect the TCK itself so the code in the eclipse microprofile-lra repo should be analysed as well. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:48:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: Martin Stefanko created JBTM-3114: ------------------------------------- Summary: [5.9.4] LRA module should depend on a specific snapshot build Key: JBTM-3114 URL: https://issues.jboss.org/browse/JBTM-3114 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.2.Final Reporter: Martin Stefanko Assignee: Michael Musgrove Fix For: 5.9.3.Final The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). The current implementation was coded against the following maven snapshot: org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20181217.132756-202 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:51:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:51:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3114: ---------------------------------- Description: The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. Current version of the implementation is running against latest build: - api - 1.0-20190222.071200-278 - tck - 1.0-20190222.071201-278 was: The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). The current implementation was coded against the following maven snapshot: org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20181217.132756-202 > [5.9.4] LRA module should depend on a specific snapshot build > ------------------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:51:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:51:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3114: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1413 > [5.9.4] LRA module should depend on a specific snapshot build > ------------------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:52:01 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:52:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3114: ---------------------------------- Affects Version/s: 5.9.3.Final (was: 5.9.2.Final) > [5.9.4] LRA module should depend on a specific snapshot build > ------------------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:52:02 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:52:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko reassigned JBTM-3114: ------------------------------------- Assignee: Martin Stefanko (was: Michael Musgrove) > [5.9.4] LRA module should depend on a specific snapshot build > ------------------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.9.3.Final > > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:53:00 2019 From: issues at jboss.org (Martin Stefanko (Jira)) Date: Fri, 22 Feb 2019 05:53:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) [5.9.4] LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stefanko updated JBTM-3114: ---------------------------------- Fix Version/s: (was: 5.9.3.Final) > [5.9.4] LRA module should depend on a specific snapshot build > ------------------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Fri Feb 22 05:56:00 2019 From: issues at jboss.org (Tom Jenkinson (Jira)) Date: Fri, 22 Feb 2019 05:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3114) LRA module should depend on a specific snapshot build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3114: -------------------------------- Summary: LRA module should depend on a specific snapshot build (was: [5.9.4] LRA module should depend on a specific snapshot build) > LRA module should depend on a specific snapshot build > ----------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b2062ea97a753300ca0L36. > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 09:32:06 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 09:32:06 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Temporarily disable LRA testing In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3115: -------------------------------------- Summary: Temporarily disable LRA testing Key: JBTM-3115 URL: https://issues.jboss.org/browse/JBTM-3115 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.3.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The CI jobs are currently failing due to LRA TCK test failures. I propose that we disable testing by default until the TCK is stabilised. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 09:34:02 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 09:34:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Temporarily disable LRA testing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3115: ----------------------------------- Description: The CI jobs are currently failing due to LRA TCK test failures. I propose that we move the tests into a separate profile so that it can be run on demand only. was: The CI jobs are currently failing due to LRA TCK test failures. I propose that we disable testing by default until the TCK is stabilised. > Temporarily disable LRA testing > ------------------------------- > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we move the tests into a separate profile so that it can be run on demand only. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 09:34:02 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 09:34:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Move LRA TCK testing into a separate profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3115: ----------------------------------- Summary: Move LRA TCK testing into a separate profile (was: Temporarily disable LRA testing) > Move LRA TCK testing into a separate profile > -------------------------------------------- > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we move the tests into a separate profile so that it can be run on demand only. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 09:41:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 09:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Make not running the LRA TCK testing the default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3115: ----------------------------------- Summary: Make not running the LRA TCK testing the default (was: Move LRA TCK testing into a separate profile) > Make not running the LRA TCK testing the default > ------------------------------------------------ > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we move the tests into a separate profile so that it can be run on demand only. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 09:42:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 09:42:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Make not running the LRA TCK testing the default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3115: ----------------------------------- Description: The CI jobs are currently failing due to LRA TCK test failures. I propose that we do not run the TCK by default by setting skipTests to true in the TCK pom was: The CI jobs are currently failing due to LRA TCK test failures. I propose that we move the tests into a separate profile so that it can be run on demand only. > Make not running the LRA TCK testing the default > ------------------------------------------------ > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we do not run the TCK by default by setting skipTests to true in the TCK pom -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Wed Feb 27 10:34:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Wed, 27 Feb 2019 10:34:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Make not running the LRA TCK testing the default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1417 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Make not running the LRA TCK testing the default > ------------------------------------------------ > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we do not run the TCK by default by setting skipTests to true in the TCK pom -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Thu Feb 28 09:27:00 2019 From: issues at jboss.org (Michael Musgrove (Jira)) Date: Thu, 28 Feb 2019 09:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3115) Make not running the LRA TCK testing the default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3115: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make not running the LRA TCK testing the default > ------------------------------------------------ > > Key: JBTM-3115 > URL: https://issues.jboss.org/browse/JBTM-3115 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The CI jobs are currently failing due to LRA TCK test failures. > I propose that we do not run the TCK by default by setting skipTests to true in the TCK pom -- This message was sent by Atlassian Jira (v7.12.1#712002)