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

Kabir Khan kabir.khan at jboss.com
Wed Dec 1 10:55:01 EST 2010 

This has been done for JBAS-8692.

Since the module xml parser includes paths not expicitly included by default I came across a few issues. They were mainly due to a misunderstanding on my part about how this is set up, and became clear when I debugged the filters. My findings might be useful to others so here they are:

1) Anything not excluded by the filter is exported
<module xmlns="urn:jboss:module:1.0" name="my.module">
    <dependencies>
        <module name="system" export="true">
            <exports>
                <exclude path="javax/accessibility"/>
            <exports>
	</dependencies>
</module>
The above will export everything apart from things in javax.accessibility and sub-packages

2) The first matched include/exclude works
<module xmlns="urn:jboss:module:1.0" name="my.module">
    <dependencies>
        <module name="system" export="true">
            <exports>
               <exclude path="javax/**"/>
                <include path="javax/accessibility"/>
            <exports>
	</dependencies>
</module>
The above will not export anything from javax sub-packages, since the exclude is checked first. To be able to export nothing apart from javax/accessibility you need to do:
<module xmlns="urn:jboss:module:1.0" name="my.module">
    <dependencies>
        <module name="system" export="true">
            <exports>
                <include path="javax/accessibility"/>
               <exclude path="javax/**"/>
            <exports>
	</dependencies>
</module>
It now picks up that javax.accessibility is included so those classes will be exported, anything else under javax. hits the exclude filter

3) javax/naming vs javax/naming/**
<module xmlns="urn:jboss:module:1.0" name="my.module">
    <dependencies>
        <module name="system" export="true">
            <exports>
                <include path="javax/naming"/>
               <exclude path="javax/**"/>
            <exports>
	</dependencies>
</module>
'javax/naming' automatically translates to everything in javax.naming AND its sub-packages such as javax.naming.spi, so classes there will be exported
<module xmlns="urn:jboss:module:1.0" name="my.module">
    <dependencies>
        <module name="system" export="true">
            <exports>
                <include path="javax/naming/**"/>
               <exclude path="javax/**"/>
            <exports>
	</dependencies>
</module>
'javax/naming/**' means ONLY sub-packages of javax.naming, so classes in for example javax.naming.spi get exported but things in javax.naming itself do not



On 29 Nov 2010, at 10:42, Kabir Khan wrote:

> Thanks David,
> 
> I'll try changing the module definitions as suggested
> On 28 Nov 2010, at 22:30, David M. Lloyd wrote:
> 
>> 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
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

More information about the jboss-as7-dev mailing list