[jboss-as7-dev] Embedded and split packages between modules and sun.boot.class.path

[David M. Lloyd]

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