https://issues.apache.org/bugzilla/show_bug.cgi?id=49271
Jesse Glick <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Jesse Glick <[email protected]> 2010-05-11 14:14:56 EDT --- The fix looks wrong to me. TraXLiaison is part of primary Ant sources, so we should not be loading *it* using some special class loader - unnecessary and risks weird CCEs. The use of getContextClassLoader in TraXLiaison.getFactory is also strange, because it relies on some undocumented side effects from the task. It seems XSLTProcess sets and restores the thread's CCL - but it only sets it in loadClass. 943143 works only because loadClass is called at all - it could throw away the result! Also, using Class.forName(String) from TraXLiaison.getFactory is probably unnecessary and wrong. Perhaps the proper fix is as follows: 1. Back out 943143; as part of assuming JDK 1.4+ I intentionally loaded TraXLiaison directly, since it does not depend on anything outside the JRE. 2. Simplify TraXLiaison.getFactory to not call Class.forName(String). It can continue to use TransformerFactory.newInstance for an unspecified factory; or Class.forName with CCL on a specified factory. (Note that if you are bothering to specify a classpath for the processor, you should very likely be specifying the factory too - else how do you know for sure what you are getting? You could be getting some unrelated factory that happened to be elsewhere in the classpath.) 3. Make XSLTProcess.execute always create loader and call setThreadContextLoader in case classpath != null; do not do this logic in loadClass. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
