I tracked the "Resolve entity failed" message to a MyEntityResolver::resolveEntity method. This seems to confirm your comment that a resolver is involved. I'm not sure how to trace TC to find out how it got there.
The javadocs describe a DTD caching mechanism in TC5 (org.apache.catalina.util::SchemaResolver) but I'm not able to follow this back into 4.1. In particular, it would be helpful if someone could tell me where the DTDs were being cached. Also, after more testing, I noticed the resolver error messages happening on the "good" systems too, just at a much-reduced rate. On both systems there is a degree of inconsistency - slower system shows fewer failures, faster system shows more failures. Perhaps there is a relevant timeout config somewhere? -BB > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 1:19 PM > To: Tomcat Users List > Subject: Re: DOCTYPE in web-app web.xml > > I'd be surprised if Tomcat wasn't using an entity resolver to load the > DTD. The > entity resolver's job would be to recognize the DTD entry and load a > corresponding one from the local server rather than downloading it from > the > internet every time. Just think, if this weren't true, Tomcat wouldn't be > able > to deploy applications when the server is not connected to the network. > I've > used Tomcat offline many times and have never had any problems. Double > check > that your spelling is correct in the DTD entry. > > Jake > > Quoting Bob Bateman <[EMAIL PROTECTED]>: > > > Hi all, > > > > I have been working with a couple different versions and platforms of > > Tomcat, and haven't been able to determine conclusively how the DOCTYPE > > directive should be interpreted. Until recently, I had always just put > > in the standard Sun lines (see below). > > > > This worked fine until a few weeks ago, when java.sun.com was down for a > > day or so. My Tomcat installation would hang briefly during > > initialization and other bad things would happen. > > > > [digression: did anyone else experience a problem with java.sun.com?] > > > > Figuring that this sort of problem could happen again I went looking for > > a way to configure TC to look for the .dtd file locally. I found a nice > > summary here: > > > > http://www.ingenio.co.uk/xml/introdtd.html > > > > tried this: > > > > <!DOCTYPE web-app SYSTEM "web-app_2_3.dtd"> > > > > and had it work on two somewhat dissimilar systems. So far so good. > > > > Yesterday I tried the SYSTEM approach on another TC (4.1.30) and found > > this error in catalina.out: > > > > Resolve entity failednull > > file:///usr/local/jakarta/jakarta-tomcat-4.1.30-src/build/web-app_2_3.dt > > d > > > > Apparently on this installation TC is looking somewhere other than in my > > WEB-INF directory. In all cases (successful or not) I had installed a > > local copy of web-app_2_3.dtd in WEB-INF, i.e. in the same directory as > > the web-app web.xml. > > > > The 2.3 Servlet spec contradicts all of this somewhat with these words > > (SRV.13.2.1): > > > > All valid web application deployment descriptors for version 2.3 > > of this specification must contain the following DOCTYPE > > declaration: > > > > <!DOCTYPE web-app PUBLIC > > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" > > "http://java.sun.com/dtd/web-app_2_3.dtd";> > > > > This seems pretty specific, and I don't find any mention of the SYSTEM > > variation in the spec. > > > > So what is the "correct" behavior? > > > > What should I do on a system that may not always have Internet > > connectivity? > > > > Is something just built or configured wrong on the misbehaving system? > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
