[
https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin...
]
David Lloyd updated WFCORE-561:
-------------------------------
Description:
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 {{jdk.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 {{jdk.api}} module.
was:
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}}s 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 {{jdk.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 {{jdk.api}} module.
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 {{jdk.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 {{jdk.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)