Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 53411 invoked by uid 500); 23 Mar 2001 23:00:08 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 53402 invoked from network); 23 Mar 2001 23:00:08 -0000 Message-ID: <3ABBD610.2F450B3D@eng.sun.com> Date: Fri, 23 Mar 2001 15:02:40 -0800 From: "Craig R. McClanahan" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Jones CC: Tomcat-Dev Subject: Re: Still have XML loading problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Kevin Jones wrote: > Yep 1.3 > > > I think the only workaround for this is to ship our own copy of > > the JAXP JAR > > files, with the "sealed" attribute removed. I'm also going to be > > talking with > > the JAXP folks about removing that in their next release. > > :-( > > What would happen if you made a special case of the JSP servlet and loaded > it early? > Could you preload jasper somewhere else? > It (the JSP servlet) is loaded early already. It (and its XML parser) are now loaded by another classloader (not sure that was true on the 22nd -- if your Tomcat 4.0 has "jasper-compiler.jar" and "jasper-runtime.jar" separated, then it is for you). The problem is the following scenario: * JSP servlet loads early, parses TLDs from the web.xml file (which causes some JAXP parser classes to be loaded). * You do something with Xerces that causes Xerces classes to be loaded, from your webapps class loader (parent of the one used by the JSP servlet). * You do something with a JSP page that causes more parser classes to be loaded (from the JSP servlet's classloader), including a class with the same fully qualified name as one of the Xerces classes you just loaded. * Under 1.2 this worked. Under 1.3 it gives sealing violation errors The only other possible workaround I can think if is to exhaustively load every single class file out of jaxp.jar and crimson.jar at startup time. That seems horrendously wasteful of memory (especially when you consider that this has to be done for each web app). > > Kevin Jones > DevelopMentor > www.develop.com Craig