Patch to Fix Translet Class-loading Usage in a Modular Environment
------------------------------------------------------------------
Key: XALANJ-2535
URL: https://issues.apache.org/jira/browse/XALANJ-2535
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: XSLTC
Affects Versions: 2.7.1
Environment: Any modular classloader environment (OSGI, JBoss Modules
(AS7), etc)
Reporter: Jason T. Greene
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
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
