Bugzilla – Full Text Bug Listing
|
Description
fountain2012
Created attachment 207966 [details]
screen shot of JNDI mapping in Jboss 7.0.2 final showing transactionmanager
Created attachment 207967 [details]
stack trace
You should be able to workaround this by subclassing org.eclipse.persistence.platform.server.jboss.JBossPlatform and org.eclipse.persistence.transaction.jboss.JBossTransactionController In JBossTransactionController change the acquireTransactionManager() method to lookup the alternate location. In JBossPlatform, change getExternalTransactionControllerClass() to return your new Transaction controller. You can tell your persistence unit to use these new classes by specifying the eclipselink.target-server persistence unit property with the classname of your new TransactionController as the value. Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines Community: Please vote for this bug if it is important to you. Votes are one of the main criteria we use to determine which bugs to fix next. Created attachment 211082 [details]
Look for AS7 TM and then AS4 (through 6) TM
I generated the attached patch from svn://dev.eclipse.org/svnroot/rt/org.eclipse.persistence/trunk. If I change into foundation/org.eclipse.persistence.core, I can build with maven successfully. I would like to test the patch more completely, do I need to just build the other foundation folders with maven? The instructions on http://wiki.eclipse.org/EclipseLink/Development/TestStatus/MOXy-Instructions didn't seem to work for me and accessing the linked EclipseLink forum gave a blank browser page (perhaps a temporary issue). Seems to be building from dev root folder now ("ant -f antbuild.xml").
Created attachment 213470 [details]
Previous patch - slightly updated
Try AS4 only in case of JNDI lookup Namimg exception (wrapped into TransactionException).
Checked the patch into both trunk (2.4) and 2.3.3. Implemementing Tom Ware's approach, the following is tested and works:
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.transaction.TransactionManager;
import org.eclipse.persistence.platform.server.jboss.JBossPlatform;
import org.eclipse.persistence.sessions.DatabaseSession;
import org.eclipse.persistence.transaction.jboss.JBossTransactionController;
public class JBossAS7ServerPlatform extends JBossPlatform {
public JBossAS7ServerPlatform(DatabaseSession newDatabaseSession) {
super(newDatabaseSession);
}
@Override
public Class<?> getExternalTransactionControllerClass() {
return JBossAS7TransactionController.class;
}
public static class JBossAS7TransactionController extends JBossTransactionController {
@Override
protected TransactionManager acquireTransactionManager() {
try {
return InitialContext.doLookup("java:jboss/TransactionManager");
} catch (NamingException ex) {
throw new UnsupportedOperationException("Couldn't get transaction manager");
}
}
}
}
If you want to support older servers, you'll want to handle the NamingException more gracefully, but for me this is just a stopgap until 2.4 / 2.3.3 .
Please consider adding jbossas7 to keywords. I'd do it, but don't have the access rights. With the checked in change, the JBoss keyword will cover AS9. (In reply to comment #12) > With the checked in change, the JBoss keyword will cover AS9. We haven't started to develop AS9 yet but am hoping that EclipseLink will switch to using the TransactionSynchronizationRegistry (TSR) instead of TransactionManager (TM) by then. Would be nice to see an EclipseLink patch show up for switching to the TSR. :) There is some discussion here http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 about introducing a standard way of looking up the TransactionManager which was rejected since the TransactionSynchronizationRegistry is supposed to be used instead (with EE servers). Scott I've just tested this with 2.4.0-RC2 and 2.3.3-M3 . In both cases an explicit "eclipselink.target-server" and adapter is still required for correct TransactionManager lookup. An Arquillian testcase that demonstrates this issue will be attached. The test uses a workaround for another issue where classes appear to have to be explicitly listed not discovered by <exclude-unlisted-classes>false</exclude-unlisted-classes>. Do you know what revision fixed this? The change was committed in April, so I'd expect it to be in the above releases. Created attachment 217678 [details]
Test case showing problem may not be fixed in 2.4.0-RC2 and 2.3.3-M3
Test case attached. See README in the archive and the code comments for details.
Could you please attach server log with the exception you are getting. Created attachment 217700 [details] Log of execution of ExplicitClassesTest.isTransactional() on 7.1.1.Final against 2.4.0-RC2 As requested, here's a log from the test run. To produce it, I: - Stopped AS7 - Installed the EclipseLink module - edited standalone/configuration/standalone.xml and in <subsystem xmlns="urn:jboss:domain:logging:1.1"> set: <logger category="org.eclipse.persistence"> <level name="TRACE"/> </logger> <logger category="org.jboss.as.jpa"> <level name="TRACE"/> </logger> - Started AS7 - Edited the test case to add @Ignore to ExplicitClassesAndTxWorkaroundTest and NoWorkaroundsTest and all test methods of ExplicitClassesTest other than isTransactional(), to reduce log spew and keep the test focused. - Quickly updated the test to integrate EclipseLink logging with JBoss logging using a de-Guava-ized version of the integration code in https://community.jboss.org/wiki/HowToUseEclipseLinkWithAS7 . This just makes the logs readable. I'll attach a new testcase with improved logging soon. - Ran "mvn clean test" - Attached the as7 log Created attachment 217702 [details] Exception produced when transactional operation fails The updated testcase with logging integration is here: https://github.com/ringerc/scrapcode/tree/master/testcases/javaee/JBossAS7-EclipseLink-Module/as7.eclipselink Created attachment 217703 [details]
Log of execution of ExplicitClassesTest.isTransactional() on 7.1.1.Final against 2.4.0-RC2
Sorry, accidentally set application/gzip for encoding on first log upload. Fixed.
Craig,
Could you also enable TRACE logging for the AS7 JBoss TM?
<logger category="com.arjuna">
<level name="TRACE" />
</logger>
It would be nice to see the output of that also.
Thanks!
Created attachment 217711 [details]
ExplicitClassesTest.isTransactional() only, with TRACE for com.arjuna
As requested, test re-run with TRACE level for com.arjuna.
Created attachment 217712 [details]
ExplicitClassesTest.isTransactional() only, with TRACE for com.arjuna
Created attachment 217713 [details]
ExplicitClassesAndTxWorkaroundTest.isTransactional() with com.arjuna TRACE
Also added a log for the same test run with the custom JBossAS7ServerPlatform visible and activated in persistence.xml. Test succeeds.
After discussion elsewhere, I've found that explicitly setting <property name="eclipselink.target-server" value="jboss"/> allows the test to pass, so this isn't the same bug. If you tell EclipseLink it's on JBoss it now (as of 2.4.0 and 2.3.3) finds the tx manager correctly. The issue is thus not that EclipseLink is using the wrong tx manager path on JBoss, but that it isn't detecting AS7 and enabling the correct integration. This bug is indeed RESOLVED FIXED, but another one is needed. My vote would be to add integration code to AS7 that automatically passes the <property name="eclipselink.target-server" value="jboss"/> in on the PersistenceProvider.createContainerEntityManagerFactory call (which requires adding an integration adapter for EclipseLink to AS7). If someone wants to contribute a patch for that, I'll work with them. We could discuss on https://community.jboss.org/en/jbossas7/dev. If no one volunteers, I can do it sometime. FYI: EclipseLink currently does not detect the server for any server. Please feel free to file an enhancement request for this functionality and provide any suggestions/patches you have. Scott: Sorry for the wasted time. I *did* post a complete test case that showed persistence.xml (and no eclipselink.target-server = jboss ) so the info was there, but the absence of a line in a testcase doesn't exactly leap out at the reader. Sorry for the confusion. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |