7:10 p.m.
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.
Then when running the deployed example it gets loaded using
module:org.jboss.ironjacamar.impl:main which in turn gets the class from
module:javax.transaction.api:main which has its own resource loader.
When starting up a normal standalone instance, in all cases the defining classloader is
the javax.transaction.api module classloader. In both embedded and standalone scenarios,
loading this class from the javax.transaction.api module gets two resource loaders. The
SystemLocalLoader, and a module local loader for javax.transaction.api. The
javax/transaction path is added to SystemLocalLoader since the JDK includes a few classes
there (InvalidTransactionException, TransactionRequiredException,
TransactionRolledbackException), so it is added from -Dsun.boot.class.path.
-In the standalone case the SystemLocalLoader is not able to load the TM class since it
was never on the system classpath, so it loads it from the module loader.
-In the embedded case the SystemLocalLoader is able to load the TM class since it is on
the app classpath, so the module loader never gets hit.
Before initializing modules -Djava.class.path is set to null, and org.jboss.modules and
org.jboss.logging is added to Module.systemPackages.
I have patched jboss-modules to create a filter for this case here:
https://github.com/kabir/jboss-modules/tree/Beta11-patch-filter but David might have a
better idea?
If I start the embedded server with this snapshot and the following system properties, the
ds testcase works fine
SecurityActions.setSystemProperty("module.include.path",
"javax/transaction/InvalidTransactionException,javax/transaction/TransactionRequiredException,javax/transaction/TransactionRolledbackException");
SecurityActions.setSystemProperty("module.exclude.path",
"javax/transaction/**");
This fix is only required for embedded, and will not have any effect during runtime of the
standalone server (apart from an extra == null check).
A simpler way to configure this might be to just specify the names of filtered packages,
e.g.
-Dmodule.filtered.paths=javax.transaction,javax.transaction.xa
and then let the SystemLocalLoader intialization internally build up the excludes/includes
depending on what it finds on
the bootstrap path, so the module.filtered.paths becomes the following filter
{
excludes={javax/transaction,javax/transaction/},
includes={javax/transaction/InvalidTransactionException,javax/transaction/TransactionRequiredException,javax/transaction/TransactionRolledbackException}
}
Apart from these packages split between sun.boot.class.path and the modules classpath,
embedded modules is exactly the same as standalone modules.
Cheers,
Kabir
11:30 p.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
11:42 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4:55 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4895
days inactive
4900
days old
3 comments
2 participants
participants (2)
-
David M. Lloyd -
Kabir Khan