Wow, thanks very much... you're exactly right:
java.class.path=/Users/bradley/Java/apache-tomcat/bin/bootstrap.jar
version.JAXP=1.1
java.ext.dirs=/Library/Java/Extensions:/System/Library/Java/
Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
Home/lib/ext
version.xerces2=Xerces-J 2.9.0
version.xerces1=not-present
version.xalan2_2=Xalan Java 2.4.1
version.xalan1=not-present
version.ant=not-present
java.version=1.5.0_16
version.DOM=2.0
version.crimson=present-unknown-version
sun.boot.class.path=/System/Library/Frameworks/JavaVM.framework/
Versions/1.5.0/Classes/classes.jar:/System/Library/Frameworks/
JavaVM.framework/Versions/1.5.0/Classes/ui.jar:/System/Library/
Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar:/System/
Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar:/
System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/
jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
Classes/charsets.jar
version.SAX=2.0
version.xalan2x=Xalan Java 2.4.1
It appears it's using Xalan 2.4.1 somehow. The strange thing is that
all we really did was upgrade the Xalan JAR from 2.6 to 2.7.1. I also
have yet to find any alternate xalan implementations in any of the JAR
files or directories mentioned above.
I'll keep looking and post back here if I find anything.
Thanks again,
Bradley
On Nov 20, 2008, at 12:38 PM, Gary L Peskin wrote:
Try running EnvironmentCheck
(http://xml.apache.org/xalan-j/faq.html#faq-N10064). It sounds like
you may
be picking up an old version of Xalan from somewhere.
HTH,
Gary
-----Original Message-----
From: Bradley Wagner [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 20, 2008 9:22 AM
To: xalan-j-users@xml.apache.org
Subject: Strange problem with BSFManager (maybe OS X only)
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
