7:30 a.m.
Comments inline.
On 11/26/2010 12:10 PM, Kabir Khan wrote:
I've got most of our demos ported across to use Arquillian, but
came across a problem when running the ds example embedded:
org.jboss.util.NestedSQLException: Error checking for a transaction.; - nested throwable:
(java.lang.reflect.UndeclaredThrowableException); - nested throwable:
(org.jboss.jca.common.JBossResourceException: Error checking for a transaction.; - nested
throwable: (java.lang.reflect.UndeclaredThrowableException))
at
org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:115)
at org.jboss.as.test.demos.ds.DsTestCase.testDatasource(DsTestCase.java:61)
Arquillian in container
...
Caused by: org.jboss.jca.common.JBossResourceException: Error checking for a
transaction.; - nested throwable: (java.lang.reflect.UndeclaredThrowableException)
at
org.jboss.jca.common.JBossResourceException.rethrowAsResourceException(JBossResourceException.java:60)
at
org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:363)
at
org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:428)
at
org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:109)
... 81 more
Caused by: java.lang.reflect.UndeclaredThrowableException
at org.jboss.jca.common.JBossResourceException.process(JBossResourceException.java:216)
at
org.jboss.jca.common.JBossResourceException.<init>(JBossResourceException.java:112)
... 85 more
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of
org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type
with name "javax/transaction/TransactionManager"
at
org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:350)
... 83 more
This does not occur when running it normally using demos against a normal standalone
instance.
In embedded on startup javax.transaction.TransactionManager gets loaded twice on startup
1) module:org.jboss.jts:main
2) org.jboss.jts.integration:main
In both these cases the defining classloader is the system classloader.
I think the problem here is rooted in using the system module in
dependencies. I suspect the source is in one or more modules which
directly import "system" without appropriate filtering. A possible
candidate is "javax.resource.api", and certainly the
"org.jboss.ironjacamar.*" modules. As far as I can see, the *only*
modules which should be importing "system" *at*all* are
"org.jboss.modules", and "javax.api".
If we can be sure that we aren't using the "system" module anywhere
except for controlled re-export cases, then we can also be sure that no
module will be able to "see" the system classpath version of these
classes - even javax.transaction which is in the system resource path
set - because it will be filtered out by secondary modules. So action
item #1 is, eliminate all secondary usage of the "system" module.
There is a secondary issue as well though. The "javax.api" module
functions by including all of the application classpath *except* for the
javax APIs which are present in the JDK *and* in one or more modules we
ship. However, if a JEE API JAR or another JAR containing a "javax.*"
package were present on the classpath, it could slip in to "javax.api"
and cause this same sort of issue. So action item #2 is, make the
filter for "javax.api" be inclusive to what we want to import rather
than excluding what we don't.
Once we accomplish these two things, we should have a much more
embedded-friendly environment.
--
- DML