Craig,
I have changed the way that the init() method loads the parser
and parses our XML files and this has fixed the problem.
This is back to using Tomcat 3.2.
Before we were doing this:
private static Parser sXMLParser;
Element root = null;
Document doc;
sXMLParser = ParserFactory.makeParser(parserClass);
sXMLParser.parse(xmlURL);
Document doc = ((DOMParser) sXMLParser).getDocument();
root = doc.getDocumentElement();
I now parse the file like this:
Element root = null;
Document doc;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
doc = builder.parse( new File(xmlURL) );
root = doc.getDocumentElement();
Does this seem OK?
I do not need to add any .jar files to the CLASSPATH just put
everything under <context>/WEB-INF/lib/*.jar and everything seems
to be working.
However, one question that I have is how can the String variable
named xmlURL in the above code snippet be an actual URL of the
form "file:///opt/somedir/somefile" instead of having to be relative
to $TOMCAT_HOME/bin/ like it needs to be right now?
Aron.
Aron Kramlik wrote:
>
> Thanks Craig, more great info.
>
> I am using Tomcat 3.2 Final Release.
> I do not see whereI might have the xml.jar file and so I don't
> think I am loading the DOM classes from a different .jar file.
> Acrtually, this makes sense since I need to put xml4j.jar in
> $TOMCAT/lib (under the CLASSPATH) for my web app to load the
> Parser.
>
> xml4j,jar must not be JAXP-compatible as this was not liked
> by Tomcat when I replaced the jaxp.jar and parser.jar files
> with it.
>
> I have downloaded, compiled and installed Tomcat 4.0 m4 and
> with the same configuration - all my .jar files live under
> CATALINA_HOME/webapps/<context>/WEB-INF/lib/*.jar - it fails
> as well.
>
> The error might be easier to track down in Tomcat 4.0 so I
> will include part of the stack trace:
> ..
> ..
> ----- Root Cause -----
> java.lang.SecurityException: sealing violation
> at java.lang.Throwable.<init>(Throwable.java:96)
> at java.lang.Exception.<init>(Exception.java:44)
> at java.lang.RuntimeException.<init>(RuntimeException.java:49)
> at java.lang.SecurityException.<init>(SecurityException.java:41)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:237)
> at java.net.URLClassLoader.access$300(URLClassLoader.java:69)
> at
> java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:544)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:203)
> at
>
>org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:648)
> ..
> ..
>
> Any more ideas?
>
> Aron.
>
> "Craig R. McClanahan" wrote:
> >
> > Aron Kramlik wrote:
> >
> > > Rob,
> > >
> > > This is great information. I wonder if you could explain
> > > why it is that I need to put xml4j.jar file under the $CLASSPATH
> > > (i.e. $TOMCAT_HOME/lib) that is loaded by an init() method of
> > > a servlet?
> > >
> >
> > Which version of Tomcat? There are different issues in each one of them.
> >
> > Tomcat 3.1 -- has problems with loading classes from some JAR files under
> > WEB-INF/lib that were fixed in 3.2. There is also a hard coded dependency on
> > using the old "Project X" parser (xml.jar) that is included with Tomcat, which
> > is on the system classpath because Tomcat needs it.
> >
> > Tomcat 3.2 -- you might be suffering from the "class loader ordering" problem,
> > which goes like this. Tomcat 3.2 follows the usual Java "class loader
> > delegation model" when searching for classes. In effect, it always starts from
> > the *top* of the hierarchy (the system class loader) instead of the bottom.
> > What that means is that if xml4j.jar includes classes with the same names as the
> > xml.jar parser (which is likely if they both include things like the DOM
> > classes), and if you put xml4j.jar in your WEB-INF/lib directory, the "wrong"
> > versions of the commonly-named classes will be loaded.
> >
> > Tomcat 3.2 also has a documented requirement for a JAXP-compatible parser. If
> > xml4j.jar is JAXP-compatible, you should be able to just replace the parser
> > shipped with Tomcat (jaxp.jar and parser.jar) with xml4j and Tomcat will be able
> > to use it as well.
> >
> > Tomcat 4.0 -- if you have the "class loader ordering" problem under 3.2, it
> > should work correctly to put xml4j.jar into WEB-INF/lib. The reason is that the
> > Servlet 2.3 spec (which Tomcat 4.0 implements) encourages the container to do
> > "bottom up" searches of class loaders -- in other words, you should be able to
> > run with xml4j.jar in WEB-INF/lib, because the classes will be loaded from there
> > first.
> >
> > Craig McClanahan
