[jboss-jira] [JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource

[Mike Mike (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071445#comment-13071445 ] 

Mike Mike commented on WFCORE-561:
----------------------------------

I got the following LinkageError:

Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "javax/sql/PooledConnection"
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
	at java.lang.Class.privateGetPublicMethods(Class.java:2651)
	at java.lang.Class.privateGetPublicMethods(Class.java:2661)
	at java.lang.Class.privateGetPublicMethods(Class.java:2667)
	at java.lang.Class.getMethods(Class.java:1467)
	at bitronix.tm.utils.PropertyUtils.getSetter(PropertyUtils.java:311)
	at bitronix.tm.utils.PropertyUtils.setDirectProperty(PropertyUtils.java:217)
	at bitronix.tm.utils.PropertyUtils.setProperty(PropertyUtils.java:83)
	at bitronix.tm.resource.common.XAPool.createXAFactory(XAPool.java:304)
	at bitronix.tm.resource.common.XAPool.<init>(XAPool.java:63)
	at bitronix.tm.resource.jdbc.PoolingDataSource.buildXAPool(PoolingDataSource.java:101)
	at bitronix.tm.resource.jdbc.PoolingDataSource.init(PoolingDataSource.java:88)
	at de.abc.def.config.DataSourceConfig.kairosDS(DataSourceConfig.java:91)
	at de.abc.def.config.DataSourceConfig$$EnhancerBySpringCGLIB$$c92e01ec.CGLIB$kairosDS$2(<generated>)
	at de.abc.def.config.DataSourceConfig$$EnhancerBySpringCGLIB$$c92e01ec$$FastClassBySpringCGLIB$$c45f5607.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
	at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:312)
	at de.abc.def.config.DataSourceConfig$$EnhancerBySpringCGLIB$$c92e01ec.kairosDS(<generated>)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:166)
	... 46 more

We are using programmatic Bitronix datasources inside our application. I found out (by -verbose:class) that the PooledConnection is loaded twice by the following Classes:

1. [Loaded javax.sql.PooledConnection from jar:file:/D:/development/jboss/wildfly-9.0.0.CR1/modules/system/layers/base/javax/sql/api/main/jboss-javax-sql-api_7.0_spec-1.0.0.Final.jar!/]
2. [Loaded javax.sql.PooledConnection from C:\Program Files\Java\jdk1.7.0_51\jre\lib\rt.jar]


What do I have to do exactly to get my application working on Wildfly?


> Class loading problem with XAResource and XADataSource
> ------------------------------------------------------
>
>                 Key: WFCORE-561
>                 URL: https://issues.jboss.org/browse/WFCORE-561
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 1.0.0.Alpha19
>
>
> We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
> The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module.  Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
> One solution is to ensure that the {{javax.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible.  Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{javax.api}} module.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)