fyi. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/> ---------- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Wed, 07 Feb 2001 18:05:04 -0800 To: [EMAIL PROTECTED] Subject: Status Report: "Sealing Violation" Problems With Xerces Several people have reported difficulties with Tomcat 4.0b1when trying to put xerces.jar (or another XML parser) in the WEB-INF/lib directory. In theory, this should work fine -- Tomcat 4.0 implements the new servlet 2.3 recommendation that local classes override ones from the shared library classpath (i.e. all the JAR files in $CATALINA_HOME/lib, which includes the JAXP 1.1 reference implementation required by Jasper). The good news: Thanks to the help of several folks in the Turbine and Jetspeed communities, I was able to accumulate enough test cases to isolate where the problem is occurring. It's definitely a problem in the Tomcat 4.0 web app class loader, which is implementing the "local override" functionality inconsistently. The bad news: Several simple fix attempts have not succeeded in making this work -- it's going to take some more digging, but I'm confident that it can be solved within a few days. At that time, I will be asking people to try a nightly build with the proposed fix, to ensure (a) that it fixes the problem for everyone encountering it; and (b) that it does not introduce other wierd things related to class loaders. For those interested in the gory details, the problem is in StandardClassLoader.findClass(), which delegates to the parent class loader prior to checking the local repositories (I'm not sure this is really correct behavior -- hence the need for some research). Consider a class like org.xml.sax.EntityResolver, which correctly exists in both Xerces and Crimson. If the Crimson version of this class is loaded first, any attempt to load other org.xml.sax.* classes from Xerces will fail with a package sealing exception, because crimson.jar is sealed. Knowing what's wrong is the biggest part of the debugging effort -- now, it's just a matter of finding the right solution. Craig McClanahan (Jon, feel free to share this status report with the Turbine and Jetspeed lists, and anyother list you know of that has reported this issue). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
