[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 2:26 PM: ---------------------------------------------------------------------- Hi, As requested, there is now a branch based on the master with the source code to run the discussed test. The following branch comparison shows the changes. https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from... This branch is called: WFLY-8954-from-master I do not have a big time window available to me. But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. And see where I might be bale to override functionality to what you suggest. The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue. https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using. I setup a smal rest service to return me the output of: {panel} (TransactionSynchronizationRegistry) initContext .doLookup("java:comp/TransactionSynchronizationRegistry"); {panel} I get a good result. {panel} {"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}} {panel} The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect. Let us see how the fishing goes... Looks promising, the changes on how the wildfly transaction controller registers on the container seem to have produced positive effect. The test passed successfully on my system right. {panel} Running org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.288 sec - in org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.33 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.047 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest Running org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.73 sec - in org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase Running org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.209 sec - in org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase Results : Tests run: 5, Failures: 0, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ {panel} I want to see what hapens on our system tests when I hack this library into my wildfly. I will soon make a provisory commit with the changes. Many thanks. was (Author: nuno.godinhomatos): Hi, As requested, there is now a branch based on the master with the source code to run the discussed test. The following branch comparison shows the changes. https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from... This branch is called: WFLY-8954-from-master I do not have a big time window available to me. But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. And see where I might be bale to override functionality to what you suggest. The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue. https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using. I setup a smal rest service to return me the output of: {panel} (TransactionSynchronizationRegistry) initContext .doLookup("java:comp/TransactionSynchronizationRegistry"); {panel} I get a good result. {panel} {"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}} {panel} The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect. Let us see how the fishing goes. Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)