Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.7.1
-
None
-
Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.)
-
None
-
Any modular classloader environment (OSGI, JBoss Modules (AS7), etc)
-
PatchAvailable
Description
XSLTC generates bytecode that relies on direct linking for both internal logic calls (against xalan impl classes) as well as user code (xsltc java external functions). This essentially requires that the xalan implementation classes and applications classes (a deployment or module) be visible on the same classloader. This contradicts a modular environment where the goal is that a module can never see another module's implementation classes, which allows for true isolation of components.
Looking at the history, the original code used getClass().getClassLoader() on a Xalan implementation class for the parent of the translet classloader. This is actually the correct way to self refer to ones internal classes, however, it will not allow translets to call deployment classes in a multi-classloader environment. To fix this problem (specifically running under tomcat) the code was changed to use the thread context class loader instead. This is the correct way to see a deployment's classes, but it is not the correct way to see xalan implementation classes. Although, it did (and still does) work on hierarchal environments like tomcat that happened to put xalan classes in a parent loader.
There are two approaches that would support all models, including modern modular environments:
1) Change the bytecode generated by xslt to be multi-classloader aware, and to use the TCCL when attempting to call an external method. All internal calls could continue as direct linking. This is the best solution, but requires significant changes to XSLTC.
2) Change the translet class loader to simulate a traditional parent-first hierarchal model as it expects. This is done by delegating to the xalan implementation classloader first, and then falling back to the TCCL. This solves the issue in a clean way that is compatible in all environments, and does not force xalan classes on the calling classloader (user's deployment). It also is a small amount of work. It does, however, have a minor drawback, which is that a translet can not reference a class with the same name as a xalan implementation class in the user/deployment classloader. This is very unlikely to be useful.
I have attached a patch for the second option, and we plan to maintain a fork with this until a solution makes its way upstream.
Thanks