> So the problem is lack of encapsulation of the essentially > global org.apache.xalan.processor.TransformFactoryImpl name > due to the proliferation of the xalan distribution. One > should be able to work around this by introducing a > org.apache.xalan.processor.TransformFactoryImpl2 that loaded > the org.apache.xalan.processor.TransformFactoryImpl visible > via the thread context class loader.
The org.apache.xalan.processor.TransformFactoryImpl visible through the TCL, for a non-scoped deployment, wouldn't be again the JDK bundled xalan, since this is loaded with the Bootstrap CL? (testing my CL knowledge here :) > We don't need xsl during bootstrap, and as far as I know we > don't have any requirements for a specific xsl version. The > jira issue is a user request to update the xalan version > since we do bundle it. So maybe just dropping it and > defaulting to the jdk version is the best approach. We really > should avoid introducing library dependencies unless they are > needed. The xalan.jar dates from jboss-3.2 and the fact that > jdk1.3 had no bundled xsl implementation. Fine, I'll remove it and see if anyone complaints :) Maybe we should go for an 4.0.4.RC2, too. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
