Now here's a little-known fact that's going to sting a lot more people: Did you know that, as of 1.4.1_02, Sun now bundles Xalan into the rt.jar? If you did, or even if you didn't, did you know that classes placed in the classpath will not override this, so if you need to get around the brokenness of the Xalan release they chose (for example, in the lib/sql connection pools) you have to hunt up how to tweak the Endorsed Standards Classes Deployment and even then you need to know that the default given in the Sun pages is different from what the Sun Linux package uses (the real one is $JAVA_HOME/jre/lib/endorsed;) and once you get past that, also be aware the launch script for Tomcat4 _overrides_ the default with a null path unless you hack it in.

Put all this together and if you ask me, Sun has shot itself in the foot again over Java.

Why on earth take an unfinished jar like the old 1.x Xalan and burn it into the core fabric of Java? Having done so, what then is the logic of making the work-around so obtuse? Maybe I should follow the community development meeting notes more closely because it seems someone's smoking something during those sessions.

I'm probably just in a crabby mood because this secret tantric circle has cost me the loss of a full day's wages hunting down just how it could be that no matter what I did, I could not avoid the ClassLoader error on line 474 of DefaultConnectionPool even though my sources had no such line, even after I'd locate'd and deleted every one of the two dozen copies of the Xalan jars on my machine. I expect I'll lose yet a few more hours when it comes time to convince my already java-nervous client that I need to inject a hack of a jar into their core dirs or the JAVA_EMBEDDED_DIR into the very core script of their production systems tomcat environment ...