We just recently upgraded to Xalan 2.7. Upon upgrading we realized
that Xalan was expecting the BSFManager for the Bean Scripting
Framework in a new package location because I guess apache took over
the BSF project from IBM. So we upgraded BSF to bsf-2.4. This solved
the problem as Xalan's ExtensionHandlerGeneral was looking for
BSFManager at org.apache.bsf.BSFManager.
However, after thinking that we had fixed the problem on Windows and
Linux, we ran into what looks to be some OS X specific issue where
Xalan on OS X was again looking for the BSFManager in the old
location: com.ibm.bsf.BSFManager:
java.lang.ClassNotFoundException: com.ibm.bsf.BSFManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at
org
.apache
.xalan
.extensions.ExtensionHandler.getClassForName(ExtensionHandler.java:149)
at
org
.apache
.xalan
.extensions
.ExtensionHandlerGeneral.<clinit>(ExtensionHandlerGeneral.java:152)
A few things that I found really odd about this:
- The code for ExtensionHandlerGeneral in Xalan 2.7.1 appears to be
looking for it in the new place org.apache.bsf.BSFManager but this
stack trace did not indicate this.
- The exact same WAR file containing Xalan and BSF works fine on
Windows and Linux.
I have re-installed tomcat, cleared any temp directories, re-deployed
this numerous times all with the same result. We've also replicated
this on three different machines running OS X. I thought it might be
something where Xalan is using some JRE specific class that is
different on OS X, but the classname and package for the BSFManager
appear to be coming directly from ExtensionHandlerGeneral and that
classname/package location in the code is different than the one I'm
seeing in this stack trace.
Any help is greatly appreciated.
Thanks,
Bradley
