From issues at jboss.org Wed Oct 1 12:24:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 1 Oct 2014 12:24:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation In-Reply-To: References: Message-ID: David Lloyd created JBTM-2266: --------------------------------- Summary: TransactionReaper is using currentTimeMillis for timeout calculation Key: JBTM-2266 URL: https://issues.jboss.org/browse/JBTM-2266 Project: JBoss Transaction Manager Issue Type: Bug Affects Versions: 5.0.3 Reporter: David Lloyd Assignee: Tom Jenkinson Priority: Minor Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However this method can change if the system time has changed. An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 12:24:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 1 Oct 2014 12:24:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated JBTM-2266: ------------------------------ Description: Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed. An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). was: Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However this method can change if the system time has changed. An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). > TransactionReaper is using currentTimeMillis for timeout calculation > -------------------------------------------------------------------- > > Key: JBTM-2266 > URL: https://issues.jboss.org/browse/JBTM-2266 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.0.3 > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Minor > > Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed. > An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 16:21:02 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Wed, 1 Oct 2014 16:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007844#comment-13007844 ] Mark Little commented on JBTM-2266: ----------------------------------- I'm not sure this really needs to be changed. This isn't a hard realtime deadline. The standards (JTA, OTS/JTS) don't require the timeout to kick in *exactly* on time. So some skew is fine. As a result I wouldn't even classify the current implementation as a bug. > TransactionReaper is using currentTimeMillis for timeout calculation > -------------------------------------------------------------------- > > Key: JBTM-2266 > URL: https://issues.jboss.org/browse/JBTM-2266 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.0.3 > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Minor > > Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed. > An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 17:13:02 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 1 Oct 2014 17:13:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2266) TransactionReaper is using currentTimeMillis for timeout calculation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated JBTM-2266: ------------------------------ Issue Type: Enhancement (was: Bug) > TransactionReaper is using currentTimeMillis for timeout calculation > -------------------------------------------------------------------- > > Key: JBTM-2266 > URL: https://issues.jboss.org/browse/JBTM-2266 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.0.3 > Reporter: David Lloyd > Assignee: Tom Jenkinson > Priority: Minor > > Noticed while browsing through some code that the TransactionReaper uses currentTimeMillis() to calculate timeouts. However the timestamp reported by this method can change in an unexpected way if the system clock is changed. > An artificial clock based on System.nanoTime() should be used instead, since while this time may vary slightly between cores, in general it will be highly accurate and, most importantly, monotonic and steady (and unaffected by changes to the system time). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 11:51:07 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 2 Oct 2014 11:51:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-622) Support for crash recovery of tx-inflow with multiple resource managers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-622: ------------------------------- Forum Reference: https://developer.jboss.org/thread/202512 > Support for crash recovery of tx-inflow with multiple resource managers > ----------------------------------------------------------------------- > > Key: JBTM-622 > URL: https://issues.jboss.org/browse/JBTM-622 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JCA, Recovery, Transaction Core > Affects Versions: 4.2.3.CP06 > Reporter: Toshiya Kobayashi > Priority: Minor > Fix For: 6.0.0 > > > JCA tx-inflow spec allows the external EIS to provide the Xid for the inflowed transaction. The TM handling the inflowed (i.e. subordinate) transaction uses this Xid verbatim when talking to RMs. > In current implementation, each RM enlisted in the subordinate tx will see the same Xid as originally provided by the EIS. This screws recovery where multiple resources are involved, since a given Xid no longer belongs to exactly one RM, but may be shared by several. We can no longer return a single XAResource to drive the recovery for a given Xid. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:26:10 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 3 Oct 2014 08:26:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2264: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/737 > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:44:11 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 3 Oct 2014 08:44:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008490#comment-13008490 ] Tom Jenkinson commented on JBTM-2264: ------------------------------------- Hi Evgeniy, I have raised a pull request for this in our transactional driver code. I have also deployed a snapshot version of Narayana with the change already in there for you to have a go with. I have tested it locally (extensively) and it works for me. I can see the SNAPSHOT over here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/narayana/jta/narayana-jta/5.0.4.Final-SNAPSHOT/. All you should need to do is change your pom to this version. Now for some background. BTM and Atomikos are not strictly spec compliant in my mind as their core transaction processing engine performs simple pointer comparison to determine if two XAResources are equivalent rather than the spec defined approach of using isSameRM. You can see the pointer comparison for yourself over here: https://github.com/bitronix/btm/blob/master/btm/src/main/java/bitronix/tm/internal/XAResourceManager.java#L194 You can see where the spec has pseudo code that demonstrates how the transaction manager is intended to use isSameRM in section "3.4.9 Identifying Resource Manager Instance" over here: https://jcp.org/en/jsr/detail?id=907 If two XAR are not equivalent you are meant to generate a new Xid for the branch and call start with TMNOFLAGS (as BTM/Atomikos will in this case, even though its technically the same RM) and if they are equivalent you use the same Xid and call start with TMJOIN (as we do). It turns out that there are a number of resource managers that return true to isSameRM but cannot handle the TMJOIN flag. It also turns out that this is a known issue with some of the drivers and Ironjacamar (Red Hats JCA implementation in Wildfly) already works around that for a number of drivers by wrapping their XAResources with an is-same-rm-override flag that returns false. The impact of this is that although your test would work in WildFly, there is a slight performance impact as the RM has two branches, plus should you touch the same tables you may be able to deadlock. Anyway, as you were using transactional driver rather than ironjacamar you have hit this issue. I have effectively backported that IJ workaround for a number of drivers which are also not compliant to our transactional driver code. The reason we haven't gone to pointer comparison is: 1. Spec compliance - we don't break that 2. There is an issue with overriding isSameRM which affects app servers performing a process known as transaction inflow. Due to limitations with the transaction inflow API (discussed at length elsewhere, for example https://issues.jboss.org/browse/JBTM-622) a transaction manager is not permitted to generate different Xids for resources. As such if we override the same rm report from the RM, RMs which correctly implement isSameRM and accept TMJOIN would be unfairly penalised as they would get: {code} xaResource1.start(xid1, TMNOFLAGS) xaResource2.start(xid1, TMNOFLAGS) {code} Which is a protocol error. Hope it helps, Tom > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:58:12 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 3 Oct 2014 08:58:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008493#comment-13008493 ] Tom Jenkinson commented on JBTM-2264: ------------------------------------- I should also mention, there is something strange that happens with Oracle when the patch is applied (I checked it affects BTM too). You can replicate the issue with the following raw XA and SQL code: {code} final OracleXADataSource xaDataSource1 = new OracleXADataSource(); ((OracleXADataSource) xaDataSource1).setNetworkProtocol("tcp"); ((OracleXADataSource) xaDataSource1).setServerName(DB_HOST); ((OracleXADataSource) xaDataSource1).setPortNumber(1521); ((OracleXADataSource) xaDataSource1).setDatabaseName(DB_SID); ((OracleXADataSource) xaDataSource1).setDriverType("thin"); ((OracleXADataSource) xaDataSource1).setUser(DB_USER1); ((OracleXADataSource) xaDataSource1).setPassword(DB_USER1); final OracleXADataSource xaDataSource2 = new OracleXADataSource(); ((OracleXADataSource) xaDataSource2).setNetworkProtocol("tcp"); ((OracleXADataSource) xaDataSource2).setServerName(DB_HOST); ((OracleXADataSource) xaDataSource2).setPortNumber(1521); ((OracleXADataSource) xaDataSource2).setDatabaseName(DB_SID); ((OracleXADataSource) xaDataSource2).setDriverType("thin"); ((OracleXADataSource) xaDataSource2).setUser(DB_USER2); ((OracleXADataSource) xaDataSource2).setPassword(DB_USER2); XAConnection xaConnection1 = xaDataSource1.getXAConnection(); XAResource xaResource1 = new IsSameRMOverrideXAResource( xaConnection1.getXAResource()); Connection connection1 = xaConnection1.getConnection(); XAConnection xaConnection2 = xaDataSource2.getXAConnection(); Uid gtrid = new Uid(); XidImple xid1 = new XidImple(gtrid, true, 1); xaResource1.start(xid1, XAResource.TMNOFLAGS); PreparedStatement preparedStatement1 = connection1 .prepareStatement("INSERT INTO jta_test (some_string) VALUES ('test')"); preparedStatement1.execute(); System.out.println(xaResource1 + " sql for " + xaConnection1); XAResource xaResource2 = new IsSameRMOverrideXAResource( xaConnection2.getXAResource()); Connection connection2 = xaConnection2.getConnection(); XidImple xid2 = new XidImple(gtrid, true, 1); xaResource2.start(xid2, XAResource.TMNOFLAGS); PreparedStatement preparedStatement2 = connection2 .prepareStatement("INSERT INTO jta_test (some_string) VALUES ('test')"); System.out.println(xaResource2 + " sql for " + xaConnection2); preparedStatement2.execute(); xaResource1.end(xid1, XAResource.TMSUCCESS); int prepare1 = xaResource1.prepare(xid1); xaResource2.end(xid2, XAResource.TMSUCCESS); int prepare2 = xaResource2.prepare(xid2); if (prepare1 != XAResource.XA_RDONLY) xaResource1.rollback(xid1); if (prepare2 != XAResource.XA_RDONLY) xaResource2.rollback(xid2); {code} That first prepare returns XAResource.XA_RDONLY. If you alter the code to use a different gtrid for each branch the resource manager returns XA_OK as expected (but obviously that is not what happens when the TM is involved as the gtrid is fixed for the TX). It appears that internally Oracle may be optimizing the SQL into the second prepare as when I reordered the prepare calls xid2 instead returned XA_RDONLY. It might be a setting on our database I am not sure. Either way you should verify that the app is performing the updates that you expect. > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 10:07:11 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 3 Oct 2014 10:07:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008517#comment-13008517 ] Mark Little commented on JBTM-2264: ----------------------------------- Tom, great write up. I suggest changing this issue from a bug to something else (feature request?) > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 10:24:11 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 3 Oct 2014 10:24:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2264: -------------------------------- Issue Type: Feature Request (was: Bug) > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 10:59:12 2014 From: issues at jboss.org (Evgeniy Smelik (JIRA)) Date: Fri, 3 Oct 2014 10:59:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008535#comment-13008535 ] Evgeniy Smelik commented on JBTM-2264: -------------------------------------- Many thanks for the prompt and comprehensive responses. > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:07:12 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 3 Oct 2014 11:07:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008540#comment-13008540 ] Tom Jenkinson commented on JBTM-2264: ------------------------------------- You are welcome! > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 03:11:11 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Mon, 6 Oct 2014 03:11:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2267) Create a docker image with JTS transaction manager and recovery manager In-Reply-To: References: Message-ID: Mark Little created JBTM-2267: --------------------------------- Summary: Create a docker image with JTS transaction manager and recovery manager Key: JBTM-2267 URL: https://issues.jboss.org/browse/JBTM-2267 Project: JBoss Transaction Manager Issue Type: Task Components: JTS Affects Versions: 5.0.3 Reporter: Mark Little Assignee: Mark Little Should help with a) using docker and b) providing transactions-as-a-service. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 03:11:11 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Mon, 6 Oct 2014 03:11:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2267) Create a docker image with JTS transaction manager and recovery manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2267 started by Mark Little. ----------------------------------------- > Create a docker image with JTS transaction manager and recovery manager > ----------------------------------------------------------------------- > > Key: JBTM-2267 > URL: https://issues.jboss.org/browse/JBTM-2267 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Mark Little > > Should help with a) using docker and b) providing transactions-as-a-service. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 05:05:11 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 05:05:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2256: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.4, 4.17.23 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 05:06:10 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 05:06:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2255: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.0.4, 4.17.23 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 07:53:10 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 07:53:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2193) NullPointerException in ThreadedTransactionTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2193: ---------------------------------- Status: Pull Request Sent (was: Reopened) Removing @Ignore from the test since this was fixed upstream > NullPointerException in ThreadedTransactionTest > ----------------------------------------------- > > Key: JBTM-2193 > URL: https://issues.jboss.org/browse/JBTM-2193 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/544/PROFILE=XTS,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.34 sec <<< FAILURE! > testThreadedTransaction(com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest) Time elapsed: 2.414 sec <<< ERROR! > com.arjuna.wst.SystemException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > {code} > {code} > [0m19:52:32,130 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-105) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,133 INFO [stdout] (Thread-107) > 19:52:32,133 INFO [stdout] (Thread-107) Thread Thread[Thread-107,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ae > 19:52:32,145 INFO [stdout] (Thread-110) > 19:52:32,145 INFO [stdout] (Thread-110) Thread Thread[Thread-110,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b1 > 19:52:32,147 INFO [stdout] (Thread-111) > 19:52:32,147 INFO [stdout] (Thread-111) Thread Thread[Thread-111,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b4 > 19:52:32,148 INFO [stdout] (Thread-112) > 19:52:32,148 INFO [stdout] (Thread-112) Thread Thread[Thread-112,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b7 > 19:52:32,150 INFO [stdout] (Thread-109) > 19:52:32,150 INFO [stdout] (Thread-109) Thread Thread[Thread-109,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ba > 19:52:32,152 INFO [stdout] (Thread-108) > 19:52:32,152 INFO [stdout] (Thread-108) Thread Thread[Thread-108,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3bd > 19:52:32,169 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-104) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,184 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] started AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,187 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils] (default task-10) SERVER_TRANSPORT_REBASE_FAILURE_MSG: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:305) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:485) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,267 INFO [stdout] (Thread-106) > 19:52:32,267 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,279 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-103) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,309 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-106) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,338 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-108) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,363 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-109) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,412 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-112) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,464 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-111) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,510 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-110) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,681 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-107) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,890 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) Interceptor for {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService#{http://docs.oasis-open.org/ws-tx/wsat/2006/06}CommitOperation has thrown exception, unwinding now: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:95) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,910 ERROR [stderr] (Thread-105) com.arjuna.wst.SystemException > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > 19:52:32,932 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-4) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,944 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-5) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,965 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,994 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,036 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-3) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,068 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,096 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,102 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,288 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-7) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,359 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test > 19:52:33,364 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0010: Stopping weld service for deployment test.war > 19:52:33,372 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 13ms > 19:52:33,483 INFO [org.jboss.as.repository] (management-handler-thread - 5) WFLYDR0002: Content removed from location /home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/3f/30c166ab2fe4bd1b3e4943a92c591d956009ad/content > 19:52:33,484 INFO [org.jboss.as.server] (management-handler-thread - 5) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") > 19:52:33,509 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: /rest-tx > 19:52:33,510 INFO [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 19:52:33,510 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-2) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033007: InboundBridgeRecoveryManager stopping > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033014: OutboundBridgeRecoveryManager stopping > 19:52:33,534 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 19:52:33,562 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 19:52:33,564 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 69) WFLYMSG0006: Unbound messaging object to jndi name java:/jms/queue/ExpiryQueue > 19:52:33,588 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment restat-web-5.0.3.Final-SNAPSHOT.war (runtime-name: restat-web-5.0.3.Final-SNAPSHOT.war) in 40ms > 19:52:33,605 INFO [org.hornetq.ra] (ServerService Thread Pool -- 73) HQ151003: HornetQ resource adaptor stopped > 19:52:33,684 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 73) HQ221002: HornetQ Server version 2.4.1.Final (Fast Hornet, 124) [1a8e9050-f005-11e3-b090-91e16d11e70b] stopped > 19:52:38,841 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122015: Can not connect to XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****] on auto-generated resource recovery: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) [hornetq-core-client-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:377) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:52:38,843 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122008: XA Recovery can not connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****]] > 19:52:38,845 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:313) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=null] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:426) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > ... 6 more > 19:52:38,887 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Periodic Recovery) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionParticipantService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-participant-binding.wsdl > 19:53:05,337 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Timer-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 19:53:09,123 WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046043: exception reactivating recovered WS-BA participant 1235: java.lang.Exception: ARJUNA043222: participant 1235 has no saved recovery state to recover > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryRecord.restoreParticipant(BAParticipantRecoveryRecord.java:155) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.recoverParticipants(XTSBARecoveryManagerImple.java:208) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.processParticipantsStatus(BAParticipantRecoveryModule.java:265) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.periodicWorkSecondPass(BAParticipantRecoveryModule.java:137) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:53:09,125 INFO [org.jboss.as.webservices] (MSC service thread 1-1) WFLYWS0004: Stopping service jboss.ws.endpoint-publish.ws-t11-client > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 07:54:11 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 07:54:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2193) NullPointerException in ThreadedTransactionTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008790#comment-13008790 ] Gytis Trikleris edited comment on JBTM-2193 at 10/6/14 7:53 AM: ---------------------------------------------------------------- Removing @Ignore from the test since this was fixed in upstream was (Author: gytis): Removing @Ignore from the test since this was fixed upstream > NullPointerException in ThreadedTransactionTest > ----------------------------------------------- > > Key: JBTM-2193 > URL: https://issues.jboss.org/browse/JBTM-2193 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/544/PROFILE=XTS,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.34 sec <<< FAILURE! > testThreadedTransaction(com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest) Time elapsed: 2.414 sec <<< ERROR! > com.arjuna.wst.SystemException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > {code} > {code} > [0m19:52:32,130 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-105) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,133 INFO [stdout] (Thread-107) > 19:52:32,133 INFO [stdout] (Thread-107) Thread Thread[Thread-107,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ae > 19:52:32,145 INFO [stdout] (Thread-110) > 19:52:32,145 INFO [stdout] (Thread-110) Thread Thread[Thread-110,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b1 > 19:52:32,147 INFO [stdout] (Thread-111) > 19:52:32,147 INFO [stdout] (Thread-111) Thread Thread[Thread-111,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b4 > 19:52:32,148 INFO [stdout] (Thread-112) > 19:52:32,148 INFO [stdout] (Thread-112) Thread Thread[Thread-112,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b7 > 19:52:32,150 INFO [stdout] (Thread-109) > 19:52:32,150 INFO [stdout] (Thread-109) Thread Thread[Thread-109,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ba > 19:52:32,152 INFO [stdout] (Thread-108) > 19:52:32,152 INFO [stdout] (Thread-108) Thread Thread[Thread-108,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3bd > 19:52:32,169 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-104) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,184 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] started AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,187 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils] (default task-10) SERVER_TRANSPORT_REBASE_FAILURE_MSG: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:305) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:485) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,267 INFO [stdout] (Thread-106) > 19:52:32,267 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,279 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-103) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,309 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-106) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,338 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-108) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,363 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-109) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,412 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-112) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,464 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-111) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,510 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-110) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,681 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-107) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,890 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) Interceptor for {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService#{http://docs.oasis-open.org/ws-tx/wsat/2006/06}CommitOperation has thrown exception, unwinding now: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:95) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,910 ERROR [stderr] (Thread-105) com.arjuna.wst.SystemException > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > 19:52:32,932 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-4) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,944 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-5) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,965 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,994 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,036 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-3) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,068 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,096 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,102 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,288 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-7) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,359 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test > 19:52:33,364 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0010: Stopping weld service for deployment test.war > 19:52:33,372 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 13ms > 19:52:33,483 INFO [org.jboss.as.repository] (management-handler-thread - 5) WFLYDR0002: Content removed from location /home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/3f/30c166ab2fe4bd1b3e4943a92c591d956009ad/content > 19:52:33,484 INFO [org.jboss.as.server] (management-handler-thread - 5) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") > 19:52:33,509 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: /rest-tx > 19:52:33,510 INFO [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 19:52:33,510 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-2) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033007: InboundBridgeRecoveryManager stopping > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033014: OutboundBridgeRecoveryManager stopping > 19:52:33,534 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 19:52:33,562 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 19:52:33,564 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 69) WFLYMSG0006: Unbound messaging object to jndi name java:/jms/queue/ExpiryQueue > 19:52:33,588 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment restat-web-5.0.3.Final-SNAPSHOT.war (runtime-name: restat-web-5.0.3.Final-SNAPSHOT.war) in 40ms > 19:52:33,605 INFO [org.hornetq.ra] (ServerService Thread Pool -- 73) HQ151003: HornetQ resource adaptor stopped > 19:52:33,684 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 73) HQ221002: HornetQ Server version 2.4.1.Final (Fast Hornet, 124) [1a8e9050-f005-11e3-b090-91e16d11e70b] stopped > 19:52:38,841 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122015: Can not connect to XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****] on auto-generated resource recovery: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) [hornetq-core-client-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:377) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:52:38,843 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122008: XA Recovery can not connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****]] > 19:52:38,845 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:313) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=null] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:426) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > ... 6 more > 19:52:38,887 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Periodic Recovery) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionParticipantService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-participant-binding.wsdl > 19:53:05,337 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Timer-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 19:53:09,123 WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046043: exception reactivating recovered WS-BA participant 1235: java.lang.Exception: ARJUNA043222: participant 1235 has no saved recovery state to recover > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryRecord.restoreParticipant(BAParticipantRecoveryRecord.java:155) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.recoverParticipants(XTSBARecoveryManagerImple.java:208) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.processParticipantsStatus(BAParticipantRecoveryModule.java:265) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.periodicWorkSecondPass(BAParticipantRecoveryModule.java:137) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:53:09,125 INFO [org.jboss.as.webservices] (MSC service thread 1-1) WFLYWS0004: Stopping service jboss.ws.endpoint-publish.ws-t11-client > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 07:54:12 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 07:54:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2193) NullPointerException in ThreadedTransactionTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2193: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/681, https://github.com/jbosstm/narayana/pull/738 (was: https://github.com/jbosstm/narayana/pull/681) > NullPointerException in ThreadedTransactionTest > ----------------------------------------------- > > Key: JBTM-2193 > URL: https://issues.jboss.org/browse/JBTM-2193 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/544/PROFILE=XTS,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.34 sec <<< FAILURE! > testThreadedTransaction(com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest) Time elapsed: 2.414 sec <<< ERROR! > com.arjuna.wst.SystemException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > {code} > {code} > [0m19:52:32,130 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-105) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,133 INFO [stdout] (Thread-107) > 19:52:32,133 INFO [stdout] (Thread-107) Thread Thread[Thread-107,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ae > 19:52:32,145 INFO [stdout] (Thread-110) > 19:52:32,145 INFO [stdout] (Thread-110) Thread Thread[Thread-110,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b1 > 19:52:32,147 INFO [stdout] (Thread-111) > 19:52:32,147 INFO [stdout] (Thread-111) Thread Thread[Thread-111,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b4 > 19:52:32,148 INFO [stdout] (Thread-112) > 19:52:32,148 INFO [stdout] (Thread-112) Thread Thread[Thread-112,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b7 > 19:52:32,150 INFO [stdout] (Thread-109) > 19:52:32,150 INFO [stdout] (Thread-109) Thread Thread[Thread-109,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ba > 19:52:32,152 INFO [stdout] (Thread-108) > 19:52:32,152 INFO [stdout] (Thread-108) Thread Thread[Thread-108,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3bd > 19:52:32,169 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-104) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,184 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] started AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,187 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils] (default task-10) SERVER_TRANSPORT_REBASE_FAILURE_MSG: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:305) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:485) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,267 INFO [stdout] (Thread-106) > 19:52:32,267 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,279 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-103) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,309 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-106) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,338 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-108) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,363 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-109) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,412 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-112) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,464 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-111) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,510 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-110) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,681 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-107) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,890 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) Interceptor for {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService#{http://docs.oasis-open.org/ws-tx/wsat/2006/06}CommitOperation has thrown exception, unwinding now: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:95) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,910 ERROR [stderr] (Thread-105) com.arjuna.wst.SystemException > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > 19:52:32,932 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-4) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,944 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-5) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,965 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,994 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,036 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-3) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,068 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,096 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,102 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,288 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-7) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,359 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test > 19:52:33,364 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0010: Stopping weld service for deployment test.war > 19:52:33,372 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 13ms > 19:52:33,483 INFO [org.jboss.as.repository] (management-handler-thread - 5) WFLYDR0002: Content removed from location /home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/3f/30c166ab2fe4bd1b3e4943a92c591d956009ad/content > 19:52:33,484 INFO [org.jboss.as.server] (management-handler-thread - 5) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") > 19:52:33,509 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: /rest-tx > 19:52:33,510 INFO [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 19:52:33,510 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-2) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033007: InboundBridgeRecoveryManager stopping > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033014: OutboundBridgeRecoveryManager stopping > 19:52:33,534 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 19:52:33,562 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 19:52:33,564 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 69) WFLYMSG0006: Unbound messaging object to jndi name java:/jms/queue/ExpiryQueue > 19:52:33,588 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment restat-web-5.0.3.Final-SNAPSHOT.war (runtime-name: restat-web-5.0.3.Final-SNAPSHOT.war) in 40ms > 19:52:33,605 INFO [org.hornetq.ra] (ServerService Thread Pool -- 73) HQ151003: HornetQ resource adaptor stopped > 19:52:33,684 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 73) HQ221002: HornetQ Server version 2.4.1.Final (Fast Hornet, 124) [1a8e9050-f005-11e3-b090-91e16d11e70b] stopped > 19:52:38,841 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122015: Can not connect to XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****] on auto-generated resource recovery: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) [hornetq-core-client-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:377) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:52:38,843 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122008: XA Recovery can not connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****]] > 19:52:38,845 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:313) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=null] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:426) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > ... 6 more > 19:52:38,887 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Periodic Recovery) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionParticipantService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-participant-binding.wsdl > 19:53:05,337 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Timer-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 19:53:09,123 WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046043: exception reactivating recovered WS-BA participant 1235: java.lang.Exception: ARJUNA043222: participant 1235 has no saved recovery state to recover > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryRecord.restoreParticipant(BAParticipantRecoveryRecord.java:155) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.recoverParticipants(XTSBARecoveryManagerImple.java:208) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.processParticipantsStatus(BAParticipantRecoveryModule.java:265) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.periodicWorkSecondPass(BAParticipantRecoveryModule.java:137) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:53:09,125 INFO [org.jboss.as.webservices] (MSC service thread 1-1) WFLYWS0004: Stopping service jboss.ws.endpoint-publish.ws-t11-client > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:31:14 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:31:14 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2225) Provide a BeanManager lookup option for use outside of WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2225: -------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/jbosstm/narayana/pull/688) > Provide a BeanManager lookup option for use outside of WildFly > -------------------------------------------------------------- > > Key: JBTM-2225 > URL: https://issues.jboss.org/browse/JBTM-2225 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > Currently the compensations API uses JNDI to lookup the CDI BeanManager. This only works inside an application server. An alternative needs to be provided for when using the API inside standalone Weld container. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:31:16 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:31:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2224) Move Compensations dependency adder to transactions subsytem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2224: -------------------------------- Status: Open (was: Pull Request Sent) > Move Compensations dependency adder to transactions subsytem > ------------------------------------------------------------ > > Key: JBTM-2224 > URL: https://issues.jboss.org/browse/JBTM-2224 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > The Compensating transactions API can now be used in standalone.xml as well as standalone-xts.xml. XTS is now only needed for distributed compensating transactions. > Therefore, it would be better to move the automatic dependency adding code to the transactions subsystem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:31:17 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:31:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2223) Fix Compensations package name to allow for other APIs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2223: -------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/jbosstm/narayana/pull/688) > Fix Compensations package name to allow for other APIs > ------------------------------------------------------ > > Key: JBTM-2223 > URL: https://issues.jboss.org/browse/JBTM-2223 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > To allow for other Compensating Transactions APIs, the CDI one needs to be moved into a CDI specific package: > 'org.jboss.narayana.compensations' -> 'org.jboss.narayana.compensations.cdi' -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:32:10 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:32:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2223) Fix Compensations package name to allow for other APIs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson closed JBTM-2223. ------------------------------- Resolution: Deferred Deferring this until we have a need for additional APIs and when we can do it in a way to limit the impact on existing users of the API. > Fix Compensations package name to allow for other APIs > ------------------------------------------------------ > > Key: JBTM-2223 > URL: https://issues.jboss.org/browse/JBTM-2223 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > To allow for other Compensating Transactions APIs, the CDI one needs to be moved into a CDI specific package: > 'org.jboss.narayana.compensations' -> 'org.jboss.narayana.compensations.cdi' -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:32:10 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:32:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2222) Rename TXFramework -> Compensations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2222: -------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/jbosstm/narayana/pull/688) > Rename TXFramework -> Compensations > ----------------------------------- > > Key: JBTM-2222 > URL: https://issues.jboss.org/browse/JBTM-2222 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > TXFramework now just focuses on Compensating transactions. The ACID transaction improvements have been moved into XTS and REST components. Therefore, we should drop the TXFramework name in favour of "Compensations" or "Compensating Transactions". -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:33:10 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:33:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2221: -------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/jbosstm/narayana/pull/688) > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:33:11 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:33:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2202) Provide local-only alternative for Compensating Transactions API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson resolved JBTM-2202. --------------------------------- Resolution: Done > Provide local-only alternative for Compensating Transactions API > ---------------------------------------------------------------- > > Key: JBTM-2202 > URL: https://issues.jboss.org/browse/JBTM-2202 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > > Currently the compensating transactions uses WS-BA under the covers, regardless of wether a distribute transaction is required. This was done as it covered both the local-only and distributed case. > However, this approach has a significant performance problem for cases where distributed transactions are not required. Therefore the developer should be able to chose a more lightweight local-only implementation that uses the Sagas model directly, rather than via the WS-BA implementation. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:34:13 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:34:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1681) EJB support for Compensations API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson closed JBTM-1681. ------------------------------- Resolution: Deferred Deferring this until we have a request to do it. > EJB support for Compensations API > --------------------------------- > > Key: JBTM-1681 > URL: https://issues.jboss.org/browse/JBTM-1681 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: TXFramework, XTS > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 6.0.0 > > > We need to be able to use all the annotations on EJBs and also allow allow the handler implementations to be EJBs. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:35:10 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:35:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1266) Upload 2012 version of training material In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-1266: -------------------------------- Assignee: Tom Jenkinson (was: Paul Robinson) > Upload 2012 version of training material > ---------------------------------------- > > Key: JBTM-1266 > URL: https://issues.jboss.org/browse/JBTM-1266 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 4.16.4 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > Attachments: txCompletion > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 08:36:12 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 08:36:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1266) Upload 2012 version of training material In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008817#comment-13008817 ] Paul Robinson commented on JBTM-1266: ------------------------------------- [~tomjenkinson] Not sure if this is relevant anymore. Let me know if you want to me to lookup these "updates" that I spoke of. > Upload 2012 version of training material > ---------------------------------------- > > Key: JBTM-1266 > URL: https://issues.jboss.org/browse/JBTM-1266 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 4.16.4 > Reporter: Paul Robinson > Assignee: Tom Jenkinson > Priority: Minor > Attachments: txCompletion > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:00:13 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 10:00:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2221: -------------------------------- Fix Version/s: 6.0.0 (was: 5.0.4) > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 6.0.0 > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:01:14 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 10:01:14 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008873#comment-13008873 ] Paul Robinson commented on JBTM-2221: ------------------------------------- Deprecating for now. > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 6.0.0 > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:02:11 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 10:02:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2151) Create a Quickstart showing MongoDB and Compensations API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson updated JBTM-2151: -------------------------------- Fix Version/s: 6.0.0 (was: 5.0.4) > Create a Quickstart showing MongoDB and Compensations API > --------------------------------------------------------- > > Key: JBTM-2151 > URL: https://issues.jboss.org/browse/JBTM-2151 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Demonstrator, TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 6.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:02:11 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 10:02:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1753) Merge TXFramework and CompensationsAPI-prototype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson closed JBTM-1753. ------------------------------- Fix Version/s: 5.0.4 (was: 6.0.0) Resolution: Done > Merge TXFramework and CompensationsAPI-prototype > ------------------------------------------------ > > Key: JBTM-1753 > URL: https://issues.jboss.org/browse/JBTM-1753 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > The current implementation of the compensations API was a quick prototype I knocked up ready for JUDCon. It needs merging into the existing TXFramework API. > This will need some investigation as there are now multiple ways of doing the same thing. We need to decide which or both to keep. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:03:12 2014 From: issues at jboss.org (Paul Robinson (JIRA)) Date: Mon, 6 Oct 2014 10:03:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1752) Investigate usage of Compensations API with MongoDB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Robinson closed JBTM-1752. ------------------------------- Fix Version/s: 5.0.4 (was: 6.0.0) Resolution: Done > Investigate usage of Compensations API with MongoDB > --------------------------------------------------- > > Key: JBTM-1752 > URL: https://issues.jboss.org/browse/JBTM-1752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TXFramework > Reporter: Paul Robinson > Assignee: Paul Robinson > Fix For: 5.0.4 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Investigate how people are currently involving a MongoDB server with other resources. > Investigate wether MongoDB could be enlisted as a compensation-based participant with other XA resources enlisted as 2PC resources. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 10:10:12 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 6 Oct 2014 10:10:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2193) NullPointerException in ThreadedTransactionTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2193: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > NullPointerException in ThreadedTransactionTest > ----------------------------------------------- > > Key: JBTM-2193 > URL: https://issues.jboss.org/browse/JBTM-2193 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana/544/PROFILE=XTS,jdk=jdk7.latest,label=linux/ > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.34 sec <<< FAILURE! > testThreadedTransaction(com.arjuna.wstx.tests.arq.basic.ThreadedTransactionTest) Time elapsed: 2.414 sec <<< ERROR! > com.arjuna.wst.SystemException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > {code} > {code} > [0m19:52:32,130 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-105) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,133 INFO [stdout] (Thread-107) > 19:52:32,133 INFO [stdout] (Thread-107) Thread Thread[Thread-107,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ae > 19:52:32,145 INFO [stdout] (Thread-110) > 19:52:32,145 INFO [stdout] (Thread-110) Thread Thread[Thread-110,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b1 > 19:52:32,147 INFO [stdout] (Thread-111) > 19:52:32,147 INFO [stdout] (Thread-111) Thread Thread[Thread-111,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b4 > 19:52:32,148 INFO [stdout] (Thread-112) > 19:52:32,148 INFO [stdout] (Thread-112) Thread Thread[Thread-112,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3b7 > 19:52:32,150 INFO [stdout] (Thread-109) > 19:52:32,150 INFO [stdout] (Thread-109) Thread Thread[Thread-109,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3ba > 19:52:32,152 INFO [stdout] (Thread-108) > 19:52:32,152 INFO [stdout] (Thread-108) Thread Thread[Thread-108,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3bd > 19:52:32,169 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-104) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,184 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] started AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,187 WARNING [org.apache.cxf.ws.addressing.impl.InternalContextUtils] (default task-10) SERVER_TRANSPORT_REBASE_FAILURE_MSG: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.ws.addressing.impl.InternalContextUtils.rebaseResponse(InternalContextUtils.java:305) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.mediate(MAPAggregatorImpl.java:485) > at org.apache.cxf.ws.addressing.impl.MAPAggregatorImpl.handleMessage(MAPAggregatorImpl.java:143) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,267 INFO [stdout] (Thread-106) > 19:52:32,267 INFO [stdout] (Thread-106) Thread Thread[Thread-106,5,main] committing AtomicTransactionIdentifier: urn:0:ffffac118321:55af0266:539600d8:3a8 > 19:52:32,279 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-103) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,309 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-106) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,338 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-108) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,363 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-109) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,412 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-112) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,464 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-111) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,510 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-110) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,681 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Thread-107) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-coordinator-binding.wsdl > 19:52:32,890 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-10) Interceptor for {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionCoordinatorService#{http://docs.oasis-open.org/ws-tx/wsat/2006/06}CommitOperation has thrown exception, unwinding now: java.lang.NullPointerException > at io.undertow.servlet.spec.HttpServletRequestImpl.getRemotePort(HttpServletRequestImpl.java:869) > at org.apache.cxf.transport.http.HttpServletRequestSnapshot.(HttpServletRequestSnapshot.java:91) > at org.apache.cxf.transport.http.AbstractHTTPDestination$1.cacheInput(AbstractHTTPDestination.java:285) > at org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:95) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api-2.7.11.jar:2.7.11] > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:97) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:195) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > 19:52:32,910 ERROR [stderr] (Thread-105) com.arjuna.wst.SystemException > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:74) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commitWithoutAck(UserTransactionImple.java:345) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple.commit(UserTransactionImple.java:111) > 19:52:32,911 ERROR [stderr] (Thread-105) at com.arjuna.wstx.tests.arq.basic.ThreadedObject.run(ThreadedTransactionTest.java:35) > 19:52:32,932 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-4) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,944 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-5) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,965 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:32,994 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,036 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-3) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,068 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,096 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,102 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-6) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,288 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-7) Creating Service {http://docs.oasis-open.org/ws-tx/wsat/2006/06}CompletionInitiatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsat/_2006/_06/wsdl/wsat-completion-initiator-binding.wsdl > 19:52:33,359 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test > 19:52:33,364 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0010: Stopping weld service for deployment test.war > 19:52:33,372 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 13ms > 19:52:33,483 INFO [org.jboss.as.repository] (management-handler-thread - 5) WFLYDR0002: Content removed from location /home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/3f/30c166ab2fe4bd1b3e4943a92c591d956009ad/content > 19:52:33,484 INFO [org.jboss.as.server] (management-handler-thread - 5) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") > 19:52:33,509 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: /rest-tx > 19:52:33,510 INFO [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory > 19:52:33,510 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-2) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA] > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033007: InboundBridgeRecoveryManager stopping > 19:52:33,530 INFO [org.jboss.jbossts.txbridge] (MSC service thread 1-1) ARJUNA033014: OutboundBridgeRecoveryManager stopping > 19:52:33,534 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 19:52:33,562 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 19:52:33,564 INFO [org.jboss.as.messaging] (ServerService Thread Pool -- 69) WFLYMSG0006: Unbound messaging object to jndi name java:/jms/queue/ExpiryQueue > 19:52:33,588 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment restat-web-5.0.3.Final-SNAPSHOT.war (runtime-name: restat-web-5.0.3.Final-SNAPSHOT.war) in 40ms > 19:52:33,605 INFO [org.hornetq.ra] (ServerService Thread Pool -- 73) HQ151003: HornetQ resource adaptor stopped > 19:52:33,684 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 73) HQ221002: HornetQ Server version 2.4.1.Final (Fast Hornet, 124) [1a8e9050-f005-11e3-b090-91e16d11e70b] stopped > 19:52:38,841 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122015: Can not connect to XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****] on auto-generated resource recovery: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] > at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) [hornetq-core-client-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:377) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:52:38,843 WARN [org.hornetq.jms.server] (Periodic Recovery) HQ122008: XA Recovery can not connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [TransportConfiguration(name=481089b1-f006-11e3-ac21-c5d0306286da, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryConfiguration = null, username=null, password=****]] > 19:52:38,845 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:313) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:74) [hornetq-jms-server-2.4.1.Final.jar:] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=null] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:426) [hornetq-jms-server-2.4.1.Final.jar:] > at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-server-2.4.1.Final.jar:] > ... 6 more > 19:52:38,887 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Periodic Recovery) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionParticipantService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-participant-binding.wsdl > 19:53:05,337 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Timer-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana at 2/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 19:53:09,123 WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046043: exception reactivating recovered WS-BA participant 1235: java.lang.Exception: ARJUNA043222: participant 1235 has no saved recovery state to recover > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryRecord.restoreParticipant(BAParticipantRecoveryRecord.java:155) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.XTSBARecoveryManagerImple.recoverParticipants(XTSBARecoveryManagerImple.java:208) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.processParticipantsStatus(BAParticipantRecoveryModule.java:265) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule.periodicWorkSecondPass(BAParticipantRecoveryModule.java:137) [jbossxts-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.3.Final-SNAPSHOT.jar:5.0.3.Final-SNAPSHOT (revision: 3680a)] > 19:53:09,125 INFO [org.jboss.as.webservices] (MSC service thread 1-1) WFLYWS0004: Stopping service jboss.ws.endpoint-publish.ws-t11-client > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 10:56:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 10:56:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2268: -------------------------------------- Summary: narayana-hqstore-jacorb fails due to missing netty class Key: JBTM-2268 URL: https://issues.jboss.org/browse/JBTM-2268 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Tom Jenkinson Fix For: 5.0.4 The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 10:57:12 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 10:57:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2268: ----------------------------------- Attachment: jstack.21302 > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 11:36:10 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 11:36:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2268: -------------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 11:36:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 11:36:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009392#comment-13009392 ] Michael Musgrove commented on JBTM-2268: ---------------------------------------- The problem is that we depend on org.hornetq:hornetq-core:2.2.14.Final which in turn depends on org.jboss.netty:netty:3.2.5.Final However commit f74623d84a683d7de7f8b23e5ba79e77fa2c0fd4 changed our qa test suite and upgraded netty to netty to 4.0.15.Final. I am backing out the fix (and will notify Ondrej) > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 11:50:10 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 11:50:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2268: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/740 > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 17:41:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 17:41:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2268: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/741 (was: https://github.com/jbosstm/narayana/pull/740) > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 17:41:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 7 Oct 2014 17:41:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2268) narayana-hqstore-jacorb fails due to missing netty class In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2268: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > narayana-hqstore-jacorb fails due to missing netty class > -------------------------------------------------------- > > Key: JBTM-2268 > URL: https://issues.jboss.org/browse/JBTM-2268 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.4 > > Attachments: jstack.21302 > > > The last run (http://172.17.131.2/job/narayana-hqstore-jacorb/74/) failed for two reasons: > 1) qa test failures because of a change of netty version: NoClassDefFoundError: org/jboss/netty/buffer/ChannelBuffers > 2) org.jboss.jbossts.qa.junit.TaskImpl stuck waiting on a lock (jstack trace attached) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 10:26:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 9 Oct 2014 10:26:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie CI test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2265: ------------------------------------ Another hang, this time in org.jboss.narayana.blacktie.jatmibroker.xatmi.TestTPConversation. jstack traces attached > BlackTie CI test hang > --------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > Attachments: jstack.27403, jstack.27697 > > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 10:26:11 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 9 Oct 2014 10:26:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie CI test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2265: ----------------------------------- Attachment: jstack.27403 jstack.27697 > BlackTie CI test hang > --------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > Attachments: jstack.27403, jstack.27697 > > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 10:53:16 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 9 Oct 2014 10:53:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie CI test hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2265: ----------------------------------- Attachment: blacktie.zip > BlackTie CI test hang > --------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > Attachments: blacktie.zip, jstack.27403, jstack.27697 > > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 07:36:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 13 Oct 2014 07:36:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2269) Transaction missing for invocation in TravelBookingTest In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2269: ------------------------------------- Summary: Transaction missing for invocation in TravelBookingTest Key: JBTM-2269 URL: https://issues.jboss.org/browse/JBTM-2269 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator, TXFramework Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana-quickstarts/110 {code} 12:00:57,517 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0021: Registered web context: /test 12:00:57,643 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "test.war" (runtime-name : "test.war") 12:00:58,403 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}HotelServiceService from WSDL: http://localhost:8080/test/HotelServiceService?wsdl 12:00:58,461 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/taxi1}Taxi1ServiceService from WSDL: http://localhost:8080/test/Taxi1ServiceService?wsdl 12:00:58,517 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/taxi2}Taxi2ServiceService from WSDL: http://localhost:8080/test/Taxi2ServiceService?wsdl 12:00:58,645 ERROR [org.jboss.as.webservices] (default task-2) WFLYWS0056: Method invocation failed with exception: Transaction is required for invocation: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:450) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:135) at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97) at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:243) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-3.0.0.Beta1.jar:3.0.0.Beta1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:744) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException ... 93 more 12:00:58,698 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-2) Application {http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}HotelServiceService#{http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}makeBooking has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Transaction is required for invocation at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163) at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:129) at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:243) at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110) at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-3.0.0.Beta1.jar:3.0.0.Beta1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:744) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] Caused by: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:450) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:135) at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97) ... 48 more Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException ... 93 more 12:00:58,976 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 07:36:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 13 Oct 2014 07:36:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2269) Compensating transaction missing for invocation in TravelBookingTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2269: ---------------------------------- Summary: Compensating transaction missing for invocation in TravelBookingTest (was: Transaction missing for invocation in TravelBookingTest) > Compensating transaction missing for invocation in TravelBookingTest > -------------------------------------------------------------------- > > Key: JBTM-2269 > URL: https://issues.jboss.org/browse/JBTM-2269 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana-quickstarts/110 > {code} > 12:00:57,517 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0021: Registered web context: /test > 12:00:57,643 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "test.war" (runtime-name : "test.war") > 12:00:58,403 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}HotelServiceService from WSDL: http://localhost:8080/test/HotelServiceService?wsdl > 12:00:58,461 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/taxi1}Taxi1ServiceService from WSDL: http://localhost:8080/test/Taxi1ServiceService?wsdl > 12:00:58,517 INFO [org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean] (default task-5) Creating Service {http://www.jboss.org/as/quickstarts/compensationsApi/travel/taxi2}Taxi2ServiceService from WSDL: http://localhost:8080/test/Taxi2ServiceService?wsdl > 12:00:58,645 ERROR [org.jboss.as.webservices] (default task-2) WFLYWS0056: Method invocation failed with exception: Transaction is required for invocation: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation > at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:450) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:135) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:243) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-3.0.0.Beta1.jar:3.0.0.Beta1] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:744) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException > ... 93 more > 12:00:58,698 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-2) Application {http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}HotelServiceService#{http://www.jboss.org/as/quickstarts/compensationsApi/travel/hotel}makeBooking has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Transaction is required for invocation > at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:267) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:129) > at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:232) > at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:69) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126) > at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) > at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:243) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:131) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-3.0.0.Beta1.jar:3.0.0.Beta1] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:744) [undertow-core-1.2.0.Beta1.jar:1.2.0.Beta1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: org.jboss.narayana.compensations.api.TransactionalException: Transaction is required for invocation > at org.jboss.narayana.compensations.impl.CompensationInterceptorMandatory.intercept(CompensationInterceptorMandatory.java:46) [txframework-5.0.4.Final-SNAPSHOT.jar:5.0.4.Final-SNAPSHOT] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.5.Final.jar:2014-09-15 07:54] > at org.jboss.narayana.quickstarts.compensationsApi.hotel.HotelServiceImpl$Proxy$_$$_WeldSubclass.makeBooking(Unknown Source) [test.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_51] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:450) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185) > at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:135) > at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149) > at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:97) > ... 48 more > Caused by: org.jboss.narayana.compensations.api.TransactionRequiredException > ... 93 more > 12:00:58,976 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0022: Unregistered web context: /test > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 14:37:37 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 13 Oct 2014 14:37:37 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2229) Issue with issue recovering AA with CMR, recovers OK but via orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011271#comment-13011271 ] RH Bugzilla Integration commented on JBTM-2229: ----------------------------------------------- mark yarborough changed the Status of [bug 1129025|https://bugzilla.redhat.com/show_bug.cgi?id=1129025] from VERIFIED to CLOSED > Issue with issue recovering AA with CMR, recovers OK but via orphan detection > ----------------------------------------------------------------------------- > > Key: JBTM-2229 > URL: https://issues.jboss.org/browse/JBTM-2229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.21, 5.0.2 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.22, 5.0.3 > > > The issue is with the CMR recovery module when it needs to update the underlying AA to modify it with the correct value from the CMR XIDS table. > If this AA does not have Serializable XARs, it will lead to the Xid being removed from XARM during getNewXAResource (via restore_state of the XARR). When the later AARM tries to recover the AA, it means a corresponding XAR for the XID cannot be located in the XARM by the XARR and an error message is reported. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 02:08:35 2014 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Fri, 17 Oct 2014 02:08:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: Ond?ej Chaloupka created JBTM-2270: -------------------------------------- Summary: When expose-all-logs is used with JTS then no participant for transaction is shown Key: JBTM-2270 URL: https://issues.jboss.org/browse/JBTM-2270 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTS Affects Versions: 4.17.23 Reporter: Ond?ej Chaloupka Assignee: Tom Jenkinson When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. This is log from operation to get type of transaction and then see all participants. Reading type of the transaction: Succesful management operation { "operation" => "read-attribute", "address" => [ ("subsystem" => "transactions"), ("log-store" => "log-store"), ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") ], "name" => "type" } with result { "outcome" => "success", "result" => "CosTransactions/XAResourceRecord" } Getting participants: Succesful management operation { "operation" => "read-children-names", "address" => [ ("subsystem" => "transactions"), ("log-store" => "log-store"), ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") ], "child-type" => "participants" } with result { "outcome" => "success", "result" => [] } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 02:08:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 17 Oct 2014 02:08:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2270: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151322 > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Tom Jenkinson > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 02:08:36 2014 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Fri, 17 Oct 2014 02:08:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka updated JBTM-2270: ----------------------------------- Assignee: Gytis Trikleris (was: Tom Jenkinson) > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:28:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Oct 2014 05:28:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2270: ----------------------------------- Fix Version/s: 6.0.0 > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:29:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Oct 2014 05:29:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012782#comment-13012782 ] Michael Musgrove commented on JBTM-2270: ---------------------------------------- JTS participant records are not in-lined with the transaction log so they appear in a separate part of the log store. The tooling only shows participants for JTA records which do have their participants inlined. Ondrej, is the Fix version field (6.0.0) ok? > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:32:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Oct 2014 05:32:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012782#comment-13012782 ] Michael Musgrove edited comment on JBTM-2270 at 10/17/14 5:31 AM: ------------------------------------------------------------------ JTS participant records are not in-lined with the transaction log so they appear in a separate part of the log store. The tooling only shows participants for JTA records which do have their participants inlined. Ondrej, is the Fix version field (6.0.0) ok? I just noticed that Gytis is down as the assignee so I will let him update that field. was (Author: mmusgrov): JTS participant records are not in-lined with the transaction log so they appear in a separate part of the log store. The tooling only shows participants for JTA records which do have their participants inlined. Ondrej, is the Fix version field (6.0.0) ok? > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:38:35 2014 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Fri, 17 Oct 2014 05:38:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012786#comment-13012786 ] Ond?ej Chaloupka commented on JBTM-2270: ---------------------------------------- Hi Mike, >From my point of view the fixed version 6.0.0 is ok as we do not have any customer request for this functionality. The expose-all-logs functionality just came from fixes of https://bugzilla.redhat.com/show_bug.cgi?id=900289. I put Gytis as assignee just because he was working on bz#1151322. Thank you Ondra > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:56:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Oct 2014 05:56:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012789#comment-13012789 ] Michael Musgrove commented on JBTM-2270: ---------------------------------------- More comments: * In the JTS case, the participant record often resides in a different object store from the transaction log so it you would need tooling that can span multiple stores in order to implement the requested feature. * We do have a JMX interface to the object store so that would need to be used to look at remote logs but the JMX server would need to be running. * Something needs to tell the tooling which object stores to look at (which is not a trivial requirement). Also, we have about 30 record types. Up until now we have added tooling support on an adhoc basis for records that are of most interest. We really need to add another method to the record interface to enforce developers to take tooling into account when they add new records. > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 10:11:35 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 17 Oct 2014 10:11:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012897#comment-13012897 ] Mark Little commented on JBTM-2270: ----------------------------------- We're unlikely to be adding records very often, so I wouldn't expend a lot of energy on this. If you do something then make it "good enough". > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 10:12:35 2014 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 17 Oct 2014 10:12:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012899#comment-13012899 ] Mark Little commented on JBTM-2270: ----------------------------------- Mike, it's also worth remembering that "appear in a separate part of the log store" may mean a completely different machine. > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 10:29:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Oct 2014 10:29:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2270) When expose-all-logs is used with JTS then no participant for transaction is shown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012911#comment-13012911 ] Michael Musgrove commented on JBTM-2270: ---------------------------------------- Yes I agree this is a non trivial feature request and one that won't be implemented any time soon. That said, it would be great if we could add the functionality but maybe keep it as optional until we have had more discussion. Perhaps for servers running in a domain we can do some integration at the console level to get at the remote object stores. > When expose-all-logs is used with JTS then no participant for transaction is shown > ----------------------------------------------------------------------------------- > > Key: JBTM-2270 > URL: https://issues.jboss.org/browse/JBTM-2270 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 4.17.23 > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > When expose-all-logs is set to true I'm not able to get any participants of the listed transaction. > This is log from operation to get type of transaction and then see all participants. > Reading type of the transaction: > Succesful management operation { > "operation" => "read-attribute", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "name" => "type" > } with result { > "outcome" => "success", > "result" => "CosTransactions/XAResourceRecord" > } > Getting participants: > Succesful management operation { > "operation" => "read-children-names", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff0a280545:2d64af2f:54378290:3c") > ], > "child-type" => "participants" > } with result { > "outcome" => "success", > "result" => [] > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 07:11:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 20 Oct 2014 07:11:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2271) ConcurrentModificationException exception raised by CMR Recovery module first pass In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2271: -------------------------------------- Summary: ConcurrentModificationException exception raised by CMR Recovery module first pass Key: JBTM-2271 URL: https://issues.jboss.org/browse/JBTM-2271 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.0.3, 4.17.23 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 4.17.24, 5.0.3 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 07:13:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 20 Oct 2014 07:13:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2271) ConcurrentModificationException exception raised by CMR Recovery module first pass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2271: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1152782 > ConcurrentModificationException exception raised by CMR Recovery module first pass > ---------------------------------------------------------------------------------- > > Key: JBTM-2271 > URL: https://issues.jboss.org/browse/JBTM-2271 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.24, 5.0.3 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 07:20:37 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 20 Oct 2014 07:20:37 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2271) ConcurrentModificationException exception raised by CMR Recovery module first pass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2271: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/744, https://github.com/jbosstm/narayana/pull/745 > ConcurrentModificationException exception raised by CMR Recovery module first pass > ---------------------------------------------------------------------------------- > > Key: JBTM-2271 > URL: https://issues.jboss.org/browse/JBTM-2271 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.24, 5.0.3 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 09:10:43 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 20 Oct 2014 09:10:43 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2272) ISE failure in CDI transactional observer methods with remote EJB call using JTS In-Reply-To: References: Message-ID: Amos Feng created JBTM-2272: ------------------------------- Summary: ISE failure in CDI transactional observer methods with remote EJB call using JTS Key: JBTM-2272 URL: https://issues.jboss.org/browse/JBTM-2272 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.0.3, 4.17.23 Reporter: Amos Feng Assignee: Amos Feng Fix For: 4.17.24, 5.0.4 See the reproduce steps in https://bugzilla.redhat.com/show_bug.cgi?id=1098127 and the description in https://issues.jboss.org/browse/WFLY-3548 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 09:29:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 20 Oct 2014 09:29:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2271) ConcurrentModificationException exception raised by CMR Recovery module first pass In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2271: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ConcurrentModificationException exception raised by CMR Recovery module first pass > ---------------------------------------------------------------------------------- > > Key: JBTM-2271 > URL: https://issues.jboss.org/browse/JBTM-2271 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.24, 5.0.3 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 09:31:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 20 Oct 2014 09:31:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2272) ISE failure in CDI transactional observer methods with remote EJB call using JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2272: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/746, https://github.com/jbosstm/narayana/pull/747 > ISE failure in CDI transactional observer methods with remote EJB call using JTS > -------------------------------------------------------------------------------- > > Key: JBTM-2272 > URL: https://issues.jboss.org/browse/JBTM-2272 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 4.17.23, 5.0.3 > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 4.17.24, 5.0.4 > > > See the reproduce steps in https://bugzilla.redhat.com/show_bug.cgi?id=1098127 > and the description in https://issues.jboss.org/browse/WFLY-3548 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 12:04:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 20 Oct 2014 12:04:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2273) Admin CLI build failed In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2273: ------------------------------------- Summary: Admin CLI build failed Key: JBTM-2273 URL: https://issues.jboss.org/browse/JBTM-2273 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana-quickstarts/112/ {code} [INFO] ------------------------------------------------------------------------ [INFO] Building BlackTie Admin CLI Tool 5.0.4.Final-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ btadmin --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ btadmin --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ btadmin --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ btadmin --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ btadmin --- [INFO] [INFO] --- maven-dependency-plugin:2.8:unpack-dependencies (unpack-test-dependencies) @ btadmin --- [INFO] Unpacking /home/hudson/.m2/repository/apache-log4cxx/contrib/log4cxx/902683/log4cxx-902683-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/.m2/repository/junit/junit/4.11/junit-4.11.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/.m2/repository/apr-1/contrib/apr-1/1.3.3/apr-1-1.3.3-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/codec/target/blacktie-codec-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/core/target/blacktie-core-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/tx/target/blacktie-tx-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/transport/target/blacktie-transport-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/xatmi/target/blacktie-xatmi-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/xsd/target/blacktie-xsd-5.0.4.Final-SNAPSHOT.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/hybrid/target/blacktie-hybrid-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" [INFO] [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-dependencies) @ btadmin --- [INFO] Copying protoc-2.4.1.3-centos54x64.zip to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/dependencies/protoc-2.4.1.3-centos54x64.zip [INFO] Copying xercesc-3.0.1-centos54x64.zip to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/dependencies/xercesc-3.0.1-centos54x64.zip [INFO] [INFO] --- maven-antrun-plugin:1.7:run (unzip) @ btadmin --- [WARNING] Parameter tasks is deprecated, use target instead [INFO] Executing tasks main: [echo] unzip dependencies to test [INFO] Executed tasks [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ btadmin --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ btadmin --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 18 source files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Help.java:[129,50] decode(java.lang.String) in java.net.URLDecoder has been deprecated [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Shutdown.java: Some input files use unchecked or unsafe operations. [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Shutdown.java: Recompile with -Xlint:unchecked for details. [INFO] [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:process-classes (process-classes) @ btadmin --- copy-check: init: package: [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes/lib [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes/include copy-idl: copy-includes: copy-libs: process-classes: [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ btadmin --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ btadmin --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 12 source files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/test-classes [INFO] [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:test-compile (test-compile) @ btadmin --- init: fileset.test.check: [echo] src/test/cpp **/*.c* gen-test-runner1: gen-test-runner2: gen-test-runner: package: test-compile: [INFO] [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:generate-exe (generate-exe) @ btadmin --- init: init-cpp-test: [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cpp-test-classes [copy] Copying 3 files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cpp-test-classes generate-exe: libnames not specified or empty. libnames not specified or empty. [cc] 1 total files to be compiled. [cc] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/test/cpp/cs.cxx: In function ?int main(int, char**)?: [cc] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/test/cpp/cs.cxx:31:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] [cc] putenv("BLACKTIE_CONFIGURATION=linux"); [cc] ^ [cc] Starting link [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' [cc] collect2: error: ld returned 1 exit status [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Blacktie C++ Plugin ............................... SUCCESS [8.183s] [INFO] BlackTie all files ................................ SUCCESS [0.626s] [INFO] Blacktie Defaults and Dependencies ................ SUCCESS [0.032s] [INFO] Blacktie C Defaults and Dependencies .............. SUCCESS [21.098s] [INFO] Blacktie Java JNI Tests ........................... SUCCESS [1.017s] [INFO] Blacktie Schemas .................................. SUCCESS [0.252s] [INFO] Blacktie CORBA Transport .......................... SUCCESS [0.018s] [INFO] Blacktie CORBA Transport Java Bindings ............ SUCCESS [1.057s] [INFO] BlackTie Messaging (via JMS) ...................... SUCCESS [10.750s] [INFO] Blacktie Java XATMI Implementation ................ SUCCESS [5.635s] [INFO] Blacktie Java NBF Implementation .................. SUCCESS [0.228s] [INFO] Blacktie Administration Services .................. SUCCESS [1:22.245s] [INFO] Blacktie Administration Services EAR .............. SUCCESS [2.325s] [INFO] Blacktie Core C++ Implementation .................. SUCCESS [13.134s] [INFO] Blacktie Codec C++ Implementation ................. SUCCESS [16.424s] [INFO] Blacktie C++ REST Transport ....................... SUCCESS [5.257s] [INFO] Blacktie Utilities ................................ SUCCESS [3.695s] [INFO] Blacktie C++ TX Client Library .................... SUCCESS [8.486s] [INFO] Blacktie C++ Hybrid Transport ..................... SUCCESS [6.268s] [INFO] Blacktie C++ XATMI Implementation ................. SUCCESS [7.711s] [INFO] Blacktie C++ Queue Client ......................... SUCCESS [4.280s] [INFO] Blacktie NBF ...................................... SUCCESS [5.005s] [INFO] BlackTie Admin CLI Tool ........................... FAILURE [1.831s] [INFO] Blacktie Server Code Generation ................... SKIPPED [INFO] Blacktie Java/C C/Java XATMI Tests ................ SKIPPED [INFO] Blacktie Distribution ............................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3:26.487s [INFO] Finished at: Sat Oct 18 01:28:34 BST 2014 [INFO] Final Memory: 65M/431M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.jboss.narayana.blacktie.plugins:blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:generate-exe (generate-exe) on project btadmin: Failed to execute: Executing Ant script: /btcpp.build.xml [generate-exe]: Failed to execute. gcc failed with return code 1 -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :btadmin UID PID PPID C STIME TTY TIME CMD hudson 2525 2522 0 Oct10 ? 00:08:00 sshd: hudson at notty hudson 2568 2525 0 Oct10 ? 00:00:00 bash -c cd '/home/hudson' && java -jar slave.jar hudson 2575 2568 0 Oct10 ? 01:36:55 java -jar slave.jar hudson 3261 32389 0 01:28 ? 00:00:00 ps -f hudson 32369 2575 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh hudson 32389 32369 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh pkill: killing pid 2468 failed: Operation not permitted pkill: killing pid 298 failed: Operation not permitted pkill: killing pid 299 failed: Operation not permitted pkill: killing pid 300 failed: Operation not permitted pkill: killing pid 301 failed: Operation not permitted pkill: killing pid 302 failed: Operation not permitted pkill: killing pid 303 failed: Operation not permitted pkill: killing pid 304 failed: Operation not permitted pkill: killing pid 305 failed: Operation not permitted pkill: killing pid 306 failed: Operation not permitted pkill: killing pid 307 failed: Operation not permitted pkill: killing pid 308 failed: Operation not permitted pkill: killing pid 309 failed: Operation not permitted pkill: killing pid 310 failed: Operation not permitted pkill: killing pid 311 failed: Operation not permitted pkill: killing pid 312 failed: Operation not permitted pkill: killing pid 313 failed: Operation not permitted pkill: killing pid 314 failed: Operation not permitted pkill: killing pid 323 failed: Operation not permitted pkill: killing pid 324 failed: Operation not permitted pkill: killing pid 327 failed: Operation not permitted pkill: killing pid 328 failed: Operation not permitted pkill: killing pid 331 failed: Operation not permitted pkill: killing pid 332 failed: Operation not permitted pkill: killing pid 333 failed: Operation not permitted UID PID PPID C STIME TTY TIME CMD hudson 2525 2522 0 Oct10 ? 00:08:00 sshd: hudson at notty hudson 2568 2525 0 Oct10 ? 00:00:00 bash -c cd '/home/hudson' && java -jar slave.jar hudson 2575 2568 0 Oct10 ? 01:36:55 java -jar slave.jar hudson 3272 32389 0 01:28 ? 00:00:00 ps -f hudson 32369 2575 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh hudson 32389 32369 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh Some tests failed: http://172.17.131.2/job/narayana-quickstarts/112/ Build step 'Execute shell' marked build as failure {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 12:04:36 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 20 Oct 2014 12:04:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2273) Admin CLI build failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013563#comment-13013563 ] Gytis Trikleris commented on JBTM-2273: --------------------------------------- http://172.17.131.2/view/Status/job/narayana-quickstarts/113/ > Admin CLI build failed > ---------------------- > > Key: JBTM-2273 > URL: https://issues.jboss.org/browse/JBTM-2273 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana-quickstarts/112/ > {code} > [INFO] ------------------------------------------------------------------------ > [INFO] Building BlackTie Admin CLI Tool 5.0.4.Final-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ btadmin --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ btadmin --- > [INFO] > [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ btadmin --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ btadmin --- > [INFO] > [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ btadmin --- > [INFO] > [INFO] --- maven-dependency-plugin:2.8:unpack-dependencies (unpack-test-dependencies) @ btadmin --- > [INFO] Unpacking /home/hudson/.m2/repository/apache-log4cxx/contrib/log4cxx/902683/log4cxx-902683-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/.m2/repository/junit/junit/4.11/junit-4.11.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/.m2/repository/apr-1/contrib/apr-1/1.3.3/apr-1-1.3.3-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/codec/target/blacktie-codec-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/core/target/blacktie-core-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/tx/target/blacktie-tx-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/transport/target/blacktie-transport-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/.m2/repository/xml-apis/xml-apis/1.3.04/xml-apis-1.3.04.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/.m2/repository/xerces/xercesImpl/2.9.1/xercesImpl-2.9.1.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/xatmi/target/blacktie-xatmi-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/xsd/target/blacktie-xsd-5.0.4.Final-SNAPSHOT.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] Unpacking /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/hybrid/target/blacktie-hybrid-5.0.4.Final-SNAPSHOT-centos54x64.jar to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cxx/test with includes "**/*" and excludes "" > [INFO] > [INFO] --- maven-dependency-plugin:2.8:copy-dependencies (copy-dependencies) @ btadmin --- > [INFO] Copying protoc-2.4.1.3-centos54x64.zip to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/dependencies/protoc-2.4.1.3-centos54x64.zip > [INFO] Copying xercesc-3.0.1-centos54x64.zip to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/dependencies/xercesc-3.0.1-centos54x64.zip > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (unzip) @ btadmin --- > [WARNING] Parameter tasks is deprecated, use target instead > [INFO] Executing tasks > main: > [echo] unzip dependencies to test > [INFO] Executed tasks > [INFO] > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ btadmin --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 1 resource > [INFO] > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ btadmin --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 18 source files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes > [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Help.java:[129,50] decode(java.lang.String) in java.net.URLDecoder has been deprecated > [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Shutdown.java: Some input files use unchecked or unsafe operations. > [WARNING] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/main/java/org/jboss/narayana/blacktie/btadmin/commands/Shutdown.java: Recompile with -Xlint:unchecked for details. > [INFO] > [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:process-classes (process-classes) @ btadmin --- > copy-check: > init: > package: > [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes/lib > [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/classes/include > copy-idl: > copy-includes: > copy-libs: > process-classes: > [INFO] > [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ btadmin --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 3 resources > [INFO] > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ btadmin --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 12 source files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/test-classes > [INFO] > [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:test-compile (test-compile) @ btadmin --- > init: > fileset.test.check: > [echo] src/test/cpp **/*.c* > gen-test-runner1: > gen-test-runner2: > gen-test-runner: > package: > test-compile: > [INFO] > [INFO] --- blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:generate-exe (generate-exe) @ btadmin --- > init: > init-cpp-test: > [mkdir] Created dir: /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cpp-test-classes > [copy] Copying 3 files to /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/target/cpp-test-classes > generate-exe: > libnames not specified or empty. > libnames not specified or empty. > [cc] 1 total files to be compiled. > [cc] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/test/cpp/cs.cxx: In function ?int main(int, char**)?: > [cc] /home/hudson/workspace/narayana-quickstarts/narayana/blacktie/btadmin/src/test/cpp/cs.cxx:31:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Blacktie C++ Plugin ............................... SUCCESS [8.183s] > [INFO] BlackTie all files ................................ SUCCESS [0.626s] > [INFO] Blacktie Defaults and Dependencies ................ SUCCESS [0.032s] > [INFO] Blacktie C Defaults and Dependencies .............. SUCCESS [21.098s] > [INFO] Blacktie Java JNI Tests ........................... SUCCESS [1.017s] > [INFO] Blacktie Schemas .................................. SUCCESS [0.252s] > [INFO] Blacktie CORBA Transport .......................... SUCCESS [0.018s] > [INFO] Blacktie CORBA Transport Java Bindings ............ SUCCESS [1.057s] > [INFO] BlackTie Messaging (via JMS) ...................... SUCCESS [10.750s] > [INFO] Blacktie Java XATMI Implementation ................ SUCCESS [5.635s] > [INFO] Blacktie Java NBF Implementation .................. SUCCESS [0.228s] > [INFO] Blacktie Administration Services .................. SUCCESS [1:22.245s] > [INFO] Blacktie Administration Services EAR .............. SUCCESS [2.325s] > [INFO] Blacktie Core C++ Implementation .................. SUCCESS [13.134s] > [INFO] Blacktie Codec C++ Implementation ................. SUCCESS [16.424s] > [INFO] Blacktie C++ REST Transport ....................... SUCCESS [5.257s] > [INFO] Blacktie Utilities ................................ SUCCESS [3.695s] > [INFO] Blacktie C++ TX Client Library .................... SUCCESS [8.486s] > [INFO] Blacktie C++ Hybrid Transport ..................... SUCCESS [6.268s] > [INFO] Blacktie C++ XATMI Implementation ................. SUCCESS [7.711s] > [INFO] Blacktie C++ Queue Client ......................... SUCCESS [4.280s] > [INFO] Blacktie NBF ...................................... SUCCESS [5.005s] > [INFO] BlackTie Admin CLI Tool ........................... FAILURE [1.831s] > [INFO] Blacktie Server Code Generation ................... SKIPPED > [INFO] Blacktie Java/C C/Java XATMI Tests ................ SKIPPED > [INFO] Blacktie Distribution ............................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 3:26.487s > [INFO] Finished at: Sat Oct 18 01:28:34 BST 2014 > [INFO] Final Memory: 65M/431M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.jboss.narayana.blacktie.plugins:blacktie-cpp-plugin:5.0.4.Final-SNAPSHOT:generate-exe (generate-exe) on project btadmin: Failed to execute: Executing Ant script: /btcpp.build.xml [generate-exe]: Failed to execute. gcc failed with return code 1 -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :btadmin > UID PID PPID C STIME TTY TIME CMD > hudson 2525 2522 0 Oct10 ? 00:08:00 sshd: hudson at notty > hudson 2568 2525 0 Oct10 ? 00:00:00 bash -c cd '/home/hudson' && java -jar slave.jar > hudson 2575 2568 0 Oct10 ? 01:36:55 java -jar slave.jar > hudson 3261 32389 0 01:28 ? 00:00:00 ps -f > hudson 32369 2575 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh > hudson 32389 32369 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh > pkill: killing pid 2468 failed: Operation not permitted > pkill: killing pid 298 failed: Operation not permitted > pkill: killing pid 299 failed: Operation not permitted > pkill: killing pid 300 failed: Operation not permitted > pkill: killing pid 301 failed: Operation not permitted > pkill: killing pid 302 failed: Operation not permitted > pkill: killing pid 303 failed: Operation not permitted > pkill: killing pid 304 failed: Operation not permitted > pkill: killing pid 305 failed: Operation not permitted > pkill: killing pid 306 failed: Operation not permitted > pkill: killing pid 307 failed: Operation not permitted > pkill: killing pid 308 failed: Operation not permitted > pkill: killing pid 309 failed: Operation not permitted > pkill: killing pid 310 failed: Operation not permitted > pkill: killing pid 311 failed: Operation not permitted > pkill: killing pid 312 failed: Operation not permitted > pkill: killing pid 313 failed: Operation not permitted > pkill: killing pid 314 failed: Operation not permitted > pkill: killing pid 323 failed: Operation not permitted > pkill: killing pid 324 failed: Operation not permitted > pkill: killing pid 327 failed: Operation not permitted > pkill: killing pid 328 failed: Operation not permitted > pkill: killing pid 331 failed: Operation not permitted > pkill: killing pid 332 failed: Operation not permitted > pkill: killing pid 333 failed: Operation not permitted > UID PID PPID C STIME TTY TIME CMD > hudson 2525 2522 0 Oct10 ? 00:08:00 sshd: hudson at notty > hudson 2568 2525 0 Oct10 ? 00:00:00 bash -c cd '/home/hudson' && java -jar slave.jar > hudson 2575 2568 0 Oct10 ? 01:36:55 java -jar slave.jar > hudson 3272 32389 0 01:28 ? 00:00:00 ps -f > hudson 32369 2575 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh > hudson 32389 32369 0 01:07 ? 00:00:00 /bin/bash -xe /tmp/hudson884782302161251351.sh > Some tests failed: http://172.17.131.2/job/narayana-quickstarts/112/ > Build step 'Execute shell' marked build as failure > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:32:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 21 Oct 2014 10:32:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2272) ISE failure in CDI transactional observer methods with remote EJB call using JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2272: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ISE failure in CDI transactional observer methods with remote EJB call using JTS > -------------------------------------------------------------------------------- > > Key: JBTM-2272 > URL: https://issues.jboss.org/browse/JBTM-2272 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 4.17.23, 5.0.3 > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 4.17.24, 5.0.4 > > > See the reproduce steps in https://bugzilla.redhat.com/show_bug.cgi?id=1098127 > and the description in https://issues.jboss.org/browse/WFLY-3548 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 01:17:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Oct 2014 01:17:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014074#comment-13014074 ] Amos Feng commented on JBTM-2260: --------------------------------- This issue is similar with JBTM-1787 as the gcc version is 4.8.2 in CentOS 7.0 and it needs to rebuild the thirdparty library > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 09:11:36 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 22 Oct 2014 09:11:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014242#comment-13014242 ] Tom Jenkinson commented on JBTM-2260: ------------------------------------- I can't upload the jar artifacts (apr, log4cxx) as Nexus imposes some conflicting requirements on needing a none-classifier version of the jar uploading at the same time to do the release but if I try to do that I fail artifact uniqueness. I have managed to release the .zip versions though. I will therefore close this Jira but perhaps you could create one to say that we should create zip versions of the dependencies for apr log4cxx. You could then create those and I can upload them if you like? Very low priority though... > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 09:11:37 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 22 Oct 2014 09:11:37 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2260. --------------------------------- Resolution: Done > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 09:55:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 22 Oct 2014 09:55:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1816) JavaIDL test wrongly excluded? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014265#comment-13014265 ] Tom Jenkinson commented on JBTM-1816: ------------------------------------- Just an FYI, there is something in com.arjuna.ats.internal.jts.orbspecific.javaidl.recoverycoordinators.JavaIdlRCServiceInit that sets the ORBServerId that needs to be done as the thing that actually initializes the orb. > JavaIDL test wrongly excluded? > ------------------------------ > > Key: JBTM-1816 > URL: https://issues.jboss.org/browse/JBTM-1816 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.0.0.M4 > > Attachments: jacorb-rc-in-object-store.tgz > > > In the JTS pom.xml within the IDLJ excludes section there is: > **/JavaIdlRecoveryUnitTest.java > Surely we shouldn't be excluding JavaIdl tests in the JavaIdl run? Should this refer to the JacORB tests instead? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 10:48:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 22 Oct 2014 10:48:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2274: ------------------------------------- Summary: Create separate assumed complete type for heuristic transactions Key: JBTM-2274 URL: https://issues.jboss.org/browse/JBTM-2274 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 4.17.24, 5.0.4 Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the record after the move. Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 10:49:36 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 22 Oct 2014 10:49:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2274: ---------------------------------- Description: Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. was: Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the record after the move. Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. > Create separate assumed complete type for heuristic transactions > ---------------------------------------------------------------- > > Key: JBTM-2274 > URL: https://issues.jboss.org/browse/JBTM-2274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.24, 5.0.4 > > > Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. > Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 11:05:36 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 22 Oct 2014 11:05:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2274: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/748 > Create separate assumed complete type for heuristic transactions > ---------------------------------------------------------------- > > Key: JBTM-2274 > URL: https://issues.jboss.org/browse/JBTM-2274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.24, 5.0.4 > > > Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. > Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 22:20:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Oct 2014 22:20:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng reopened JBTM-2260: ----------------------------- I have to reopen it to change the build.sh script to detect the CentOS 7 and set the bpa to "centos70x64" > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 22:22:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Oct 2014 22:22:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2275) Create the zip airtifact of apr and log4cxx In-Reply-To: References: Message-ID: Amos Feng created JBTM-2275: ------------------------------- Summary: Create the zip airtifact of apr and log4cxx Key: JBTM-2275 URL: https://issues.jboss.org/browse/JBTM-2275 Project: JBoss Transaction Manager Issue Type: Task Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 22:23:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 22 Oct 2014 22:23:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2275) Create the zip airtifact of apr and log4cxx In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2275: ---------------------------- Description: Nexus imposes some conflicting requirements on needing a none-classifier version of the jar uploading at the same time to do the release > Create the zip airtifact of apr and log4cxx > ------------------------------------------- > > Key: JBTM-2275 > URL: https://issues.jboss.org/browse/JBTM-2275 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Trivial > > Nexus imposes some conflicting requirements on needing a none-classifier version of the jar uploading at the same time to do the release -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 01:29:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 01:29:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2260: ---------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/749 > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 02:56:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 02:56:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2276) Blacktie subsystem build fails In-Reply-To: References: Message-ID: Amos Feng created JBTM-2276: ------------------------------- Summary: Blacktie subsystem build fails Key: JBTM-2276 URL: https://issues.jboss.org/browse/JBTM-2276 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration, BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.0.4 It needs to upgrade the wildfly build-tools and the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 02:57:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 02:57:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2276) Blacktie subsystem build fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2276: ---------------------------- Issue Type: Bug (was: Task) > Blacktie subsystem build fails > ------------------------------ > > Key: JBTM-2276 > URL: https://issues.jboss.org/browse/JBTM-2276 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > > It needs to upgrade the wildfly build-tools and the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 03:01:36 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 03:01:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2276) Blacktie subsystem build fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2276: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/750 > Blacktie subsystem build fails > ------------------------------ > > Key: JBTM-2276 > URL: https://issues.jboss.org/browse/JBTM-2276 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > > It needs to upgrade the wildfly build-tools and the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 03:46:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 23 Oct 2014 03:46:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2275) Create the zip airtifact of apr and log4cxx In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014489#comment-13014489 ] Tom Jenkinson commented on JBTM-2275: ------------------------------------- Just a comment that this will need to be done for all the bpa that we have in CI. I think that is centos70x64, vc9x32, centos54x64, centos55x32. > Create the zip airtifact of apr and log4cxx > ------------------------------------------- > > Key: JBTM-2275 > URL: https://issues.jboss.org/browse/JBTM-2275 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Trivial > > Nexus imposes some conflicting requirements on needing a none-classifier version of the jar uploading at the same time to do the release -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 09:44:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 09:44:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2276) Blacktie subsystem build fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2276: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Blacktie subsystem build fails > ------------------------------ > > Key: JBTM-2276 > URL: https://issues.jboss.org/browse/JBTM-2276 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.4 > > > It needs to upgrade the wildfly build-tools and the server-provisioning.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 21:29:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 23 Oct 2014 21:29:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2260: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 05:47:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 27 Oct 2014 05:47:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2274: ---------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/748, https://github.com/jbosstm/narayana/pull/751 (was: https://github.com/jbosstm/narayana/pull/748) > Create separate assumed complete type for heuristic transactions > ---------------------------------------------------------------- > > Key: JBTM-2274 > URL: https://issues.jboss.org/browse/JBTM-2274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.24, 5.0.4 > > > Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. > Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 05:56:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 27 Oct 2014 05:56:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2277) Soatest node runs out of memory In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2277: ------------------------------------- Summary: Soatest node runs out of memory Key: JBTM-2277 URL: https://issues.jboss.org/browse/JBTM-2277 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Reporter: Gytis Trikleris Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.0.4 http://172.17.131.2/view/Status/job/narayana-AS800/628/ {code} [ERROR] GC overhead limit exceeded -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 05:57:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 27 Oct 2014 05:57:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2277) Soatest node runs out of memory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015188#comment-13015188 ] Gytis Trikleris commented on JBTM-2277: --------------------------------------- http://172.17.131.2/view/Status/job/narayana-AS800/629/ http://172.17.131.2/view/Status/job/narayana-AS800/630/ > Soatest node runs out of memory > ------------------------------- > > Key: JBTM-2277 > URL: https://issues.jboss.org/browse/JBTM-2277 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.0.4 > > > http://172.17.131.2/view/Status/job/narayana-AS800/628/ > {code} > [ERROR] GC overhead limit exceeded -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 28 06:50:36 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 28 Oct 2014 06:50:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2278) Allow the transaction manager suspend operation to succeed for JTS mode In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2278: ----------------------------------- Summary: Allow the transaction manager suspend operation to succeed for JTS mode Key: JBTM-2278 URL: https://issues.jboss.org/browse/JBTM-2278 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTS Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.4 It is not possible to perform TransactionManager::suspend operation during an afterCompletion call when the server is configured for JTS and has JacORB configured with interposition interceptors. This is because the transaction has not been used on the thread yet and when OTSManager.current() operation finds the PropagationContext in PICurrent to tries to recreate the hierarchy and ArjunaTransactionImple register_resource detects the transaction is no longer active so throws an Inactive exception causing suspend to fail. SystemException is a valid response code from suspend but it would be desirable to try to avoid this when the transaction is local to the Synchronization. Allowing suspend means this code would work: public afterCompletion(status) { tm.suspend() tm.begin() tm.commit() } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 28 06:54:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 28 Oct 2014 06:54:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2278) Allow the transaction manager suspend operation to succeed for JTS mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2278: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/752 > Allow the transaction manager suspend operation to succeed for JTS mode > ----------------------------------------------------------------------- > > Key: JBTM-2278 > URL: https://issues.jboss.org/browse/JBTM-2278 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > It is not possible to perform TransactionManager::suspend operation during an afterCompletion call when the server is configured for JTS and has JacORB configured with interposition interceptors. This is because the transaction has not been used on the thread yet and when OTSManager.current() operation finds the PropagationContext in PICurrent to tries to recreate the hierarchy and ArjunaTransactionImple register_resource detects the transaction is no longer active so throws an Inactive exception causing suspend to fail. > SystemException is a valid response code from suspend but it would be desirable to try to avoid this when the transaction is local to the Synchronization. > Allowing suspend means this code would work: > public afterCompletion(status) { > tm.suspend() > tm.begin() > tm.commit() > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 28 09:14:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 28 Oct 2014 09:14:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2264: -------------------------------- Fix Version/s: 5.0.4 > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-connection-from-pool]. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 11:14:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 29 Oct 2014 11:14:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2279) Provide a way to allow the override a set CheckedActionFactory In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2279: ----------------------------------- Summary: Provide a way to allow the override a set CheckedActionFactory Key: JBTM-2279 URL: https://issues.jboss.org/browse/JBTM-2279 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transaction Core Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.4 Out of the box the BasicAction caches the reference to the checkedactionfactory and so if a users classpath is not available to narayana there is no way for a user to provide a CAF to Narayana. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 11:15:38 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 29 Oct 2014 11:15:38 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2279) Provide a way to allow the override a set CheckedActionFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2279: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/755 > Provide a way to allow the override a set CheckedActionFactory > -------------------------------------------------------------- > > Key: JBTM-2279 > URL: https://issues.jboss.org/browse/JBTM-2279 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > Out of the box the BasicAction caches the reference to the checkedactionfactory and so if a users classpath is not available to narayana there is no way for a user to provide a CAF to Narayana. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 11:16:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 29 Oct 2014 11:16:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2279) Provide a way to allow overriding of a set CheckedActionFactory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2279: -------------------------------- Summary: Provide a way to allow overriding of a set CheckedActionFactory (was: Provide a way to allow the override a set CheckedActionFactory) > Provide a way to allow overriding of a set CheckedActionFactory > --------------------------------------------------------------- > > Key: JBTM-2279 > URL: https://issues.jboss.org/browse/JBTM-2279 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > Out of the box the BasicAction caches the reference to the checkedactionfactory and so if a users classpath is not available to narayana there is no way for a user to provide a CAF to Narayana. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 12:46:35 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 29 Oct 2014 12:46:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2259: ----------------------------------- Fix Version/s: 6.0.0 (was: 5.0.4) Moving out to 6 since there is a workaround: "WildFly disables the delistResource calls in beforeCompletion, and IronJacamar kills the ManagedConnection if it detects a problem in afterCompletion." We should push for ordering semantics in the next revision of the JTA spec: There is a discussion in the comments to https://java.net/jira/browse/JTA_SPEC-4 and there are also some comments in JTA_SPEC-11 > Allow the ordering of some synchronizations to be configurable > --------------------------------------------------------------- > > Key: JBTM-2259 > URL: https://issues.jboss.org/browse/JBTM-2259 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.0.0 > > > IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). > The request is to add a configuration option to control the order in which certain synchronizations are called. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 07:16:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 30 Oct 2014 07:16:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2274: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080140 > Create separate assumed complete type for heuristic transactions > ---------------------------------------------------------------- > > Key: JBTM-2274 > URL: https://issues.jboss.org/browse/JBTM-2274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.24, 5.0.4 > > > Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. > Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 07:17:35 2014 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 30 Oct 2014 07:17:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2274) Create separate assumed complete type for heuristic transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016025#comment-13016025 ] Gytis Trikleris commented on JBTM-2274: --------------------------------------- I have already merged pull request for 4.17. Now waiting for the CI nodes to get back online to retest master. > Create separate assumed complete type for heuristic transactions > ---------------------------------------------------------------- > > Key: JBTM-2274 > URL: https://issues.jboss.org/browse/JBTM-2274 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.24, 5.0.4 > > > Currently all JTS transaction records are moved to assumed complete store after 3 recovery tries. This is not good if the transaction has a heuristic outcome. It leads to the heuristic participant being rolled back, because recovery coordinator cannot see the log record after the move. > Creating separate locations for such heuristic transactions and checking their status during replay_completion would solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 23:18:36 2014 From: issues at jboss.org (Gavin King (JIRA)) Date: Thu, 30 Oct 2014 23:18:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: Gavin King created JBTM-2280: -------------------------------- Summary: alternative to JNDI Key: JBTM-2280 URL: https://issues.jboss.org/browse/JBTM-2280 Project: JBoss Transaction Manager Issue Type: Feature Request Reporter: Gavin King Assignee: Tom Jenkinson So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a total distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't case where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 23:20:35 2014 From: issues at jboss.org (Gavin King (JIRA)) Date: Thu, 30 Oct 2014 23:20:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin King updated JBTM-2280: ----------------------------- Description: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. was: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a total distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't case where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 23:25:35 2014 From: issues at jboss.org (Gavin King (JIRA)) Date: Thu, 30 Oct 2014 23:25:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin King updated JBTM-2280: ----------------------------- Description: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. was: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JDNI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 23:26:35 2014 From: issues at jboss.org (Gavin King (JIRA)) Date: Thu, 30 Oct 2014 23:26:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin King updated JBTM-2280: ----------------------------- Description: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. was: So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. XADataSource xads = youJustDontNeedToCare(); DataSource ds = narayana.registerDataSource(xads); Or something like that. Of course I'm sure I'm missing some subtleties here. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 05:59:35 2014 From: issues at jboss.org (Stephane Epardaud (JIRA)) Date: Fri, 31 Oct 2014 05:59:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016312#comment-13016312 ] Stephane Epardaud commented on JBTM-2280: ----------------------------------------- Suggestimate suggests that this is similar to JBTM-2225, which appears to be true, no? > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 06:24:36 2014 From: issues at jboss.org (Gavin King (JIRA)) Date: Fri, 31 Oct 2014 06:24:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016327#comment-13016327 ] Gavin King commented on JBTM-2280: ---------------------------------- Well, I guess it's _similar_, but not quite the same since that other issue is about the CDI `BeanManager`, not about `DataSource`s. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 06:25:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Oct 2014 06:25:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016329#comment-13016329 ] Tom Jenkinson commented on JBTM-2280: ------------------------------------- Hi Gavin, This would be best as a discussion on the Narayana forum: https://community.jboss.org/en/jbosstm Two brief points: 1. Narayana is not a JCA implementation, its a transaction manager. The core transaction manager is not connection aware, it is however XAResource aware and so for spec compliance the psuedocode you showed would be closest phrased as: XADataSource xads = youJustDontNeedTo(); XAResource xar = xads.getXAConnection().getXAResource(); narayana.getTransactionManager().getTransaction().enlistResource(xar) 2. However, we do have something called a transactional driver which does broadly what you are speaking of, its **not in product** but does allow you to pass an XADataSource to it. I have just updated our unit test to use h2 so you can see it in action: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jdbc/tests/classes/com/hp/mwtests/ts/jdbc/basic/JDBC2Test.java I think we should close this as not a bug and move the discussion onto the forum. Tom > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 06:50:35 2014 From: issues at jboss.org (Stephane Epardaud (JIRA)) Date: Fri, 31 Oct 2014 06:50:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016341#comment-13016341 ] Stephane Epardaud commented on JBTM-2280: ----------------------------------------- [~mmusgrov]: would this be enough to get rid of JNDI for us entirely then? > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 09:42:36 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 31 Oct 2014 09:42:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016403#comment-13016403 ] Michael Musgrove commented on JBTM-2280: ---------------------------------------- I can look into providing an implementation using this approach. Our docs do say "This is not recommended, but provides a fallback for environments where use of JNDI is not feasible" but I do not know why it's not recommended - I will find out. But given that we have ceylon.transaction fully working with the JNDI approach why do we need to jettison its use? > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 09:46:35 2014 From: issues at jboss.org (Stephane Epardaud (JIRA)) Date: Fri, 31 Oct 2014 09:46:35 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2280) alternative to JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016406#comment-13016406 ] Stephane Epardaud commented on JBTM-2280: ----------------------------------------- Well, I think [~gavinking] tried to refactor it and failed because the TCCL calls were actually working by accident/luck rather than by design. So when he refactored it everything stopped working and he could not figure out how to fix it. > alternative to JNDI > ------------------- > > Key: JBTM-2280 > URL: https://issues.jboss.org/browse/JBTM-2280 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gavin King > Assignee: Tom Jenkinson > > So far four (4) different people have tried and failed to get JBoss Transactions working in a Ceylon environment (i.e. JBoss Modules, essentially). The basic problem is that the TM has a totally spurious dependence on JNDI as the source of its transactional resources. Since JCA is neither defined nor available outside a Java EE environment, this forces anyone trying to use the TM outside of the application server to write their own nasty code depending on some really internal-looking APIs that basically sets up a JNDI-bound proxied datasource where both the TM and the application can find it. In principle this is sorta-straightforward (except for the internal-looking APIs). However, it means that most of the code in `ceylon.transaction` is actually about connection management and setting up JNDI-bound datasources. > Sadly it turns out that, in the context of JBoss Modules, even just getting a JNDI server on the right classloader has proved to be a task so difficult that four reasonably competent developers including myself and other folks who are much better programmers than me have failed at it. I'm sure it's remotely _possible_, and I'm sure that if I weren't using JBoss Modules it would be quite easy. But I'm also sure that it simply shouldn't be necessary. JNDI has nothing to do with transactions and is a distraction here. JNDI is this totally stringly-typed rubbish thing designed in the Clinton era as an abstraction of LDAP by folks who had never heard that Java has static types. Yeah, sure, it continues its zombie existence at the heart of the EE standards, even after we remembered that Java has static types in EE 6, but it just has no place in modern APIs. Other libraries like Hibernate, Spring, etc always offer alternative approaches with no dependence to JNDI. > IMO, what the TM _should_ do is offer an API that lets me hand it an instance of `XADataSource` (it doesn't care where that comes from) and hands my back an instance of `DataSource` that I can use to obtain transaction-bound connections. There is no reason, AFAICT, to involve JNDI in this at all. > XADataSource xads = youJustDontNeedToCare(); > DataSource ds = narayana.registerDataSource(xads); > Or something like that. Of course I'm sure I'm missing some subtleties here. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 10:59:36 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Oct 2014 10:59:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2281) Merge the documentation manuals together In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2281: ----------------------------------- Summary: Merge the documentation manuals together Key: JBTM-2281 URL: https://issues.jboss.org/browse/JBTM-2281 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Documentation Reporter: Tom Jenkinson Assignee: Gytis Trikleris The documentation for our project is available here: Narayana Documentation 5.0.2.Final - JBoss Community As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 11:03:36 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 31 Oct 2014 11:03:36 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2281) Merge the documentation manuals together In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2281: -------------------------------- Description: The documentation for our project is available here: Narayana Documentation 5.0.2.Final - JBoss Community As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals was: The documentation for our project is available here: Narayana Documentation 5.0.2.Final - JBoss Community As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. > Merge the documentation manuals together > ---------------------------------------- > > Key: JBTM-2281 > URL: https://issues.jboss.org/browse/JBTM-2281 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > > The documentation for our project is available here: > Narayana Documentation 5.0.2.Final - JBoss Community > > As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. > One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals -- This message was sent by Atlassian JIRA (v6.3.1#6329)