Xalan.jar can't ever be deployed in a .war?

Question

          I'm using WLS 6.1 SP3.
          Even when xalan.jar is bundled in a .war at /WEB-INF/lib, trying to use the Xalan
          classes results in the following exception:
          javax.xml.transform.TransformerFactoryConfigurationError: java.lang.ClassNotFoundException:
          org.apache.xalan.processor.TransformerFactoryImpl
          at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:121)
          The most commonly recommended solution is to add xalan.jar to the system classpath
          prior to starting WLS. And xalan.jar should come before weblogic.jar in the classpath.
          I see this workaround commonly recommended, but I've yet to see an explanation
          as to why it's neccesary. Given that I'd rather not have libs in the system classpath
          unless it's absolutely necessary (since they can't be dynamically redeployed),
          I want to make sure I understand the reasons behind adding xalan.jar to the system
          classpath. Here's my understanding. Let me know how mistaken I am. :-)
          Even though xalan.jar isn't needed at startup, xalan.jar needs to be in the system
          classpath instead of just contained within the .war. This is because weblogic.jar
          contains the javax.xml.transform.TransformerFactory class. And even though the
          system property "javax.xml.transform.TransformerFactory" is set to "org.apache.xalan.processor.TransformerFactoryImpl"
          by default, the parent classloader (i.e. the system classloader which has loaded
          TransformerFactory from weblogic.jar) can't see the Xalan classes it needs from
          the child classloader (i.e. a .war classloader that would contain xalan.jar.)
          Is this assertion correct? Classloader hierarchy issues?
          Thanks,
          Matt
          

Answer 1

Assuming you can't use the weblogic-application semantics in a WAR, you might consider using a servlet context listener. I don't know exactly what context you need to have available for this task, but when the context is about to be destroyed, the "contextDestroyed()" method of the context listener will be called, which might be sufficient for your needs.