- I have Tomcat 4.1.12 with 1 context (my application).
you should upgrade. 4.1.29 is out and Tomcat-5, my personal favorite, is just about to be fully released as 5.0.15 (or whichever version they decide).
Ah, yes, but company prescribed versions and stuff are always a bummer.
- In the Tomcat directory is no log4j.jar or properties.
"in the Tomcat directory"? What does that mean? TOMCAT_HOME?
Nowhere in the Tomcat directory; not in the server, not in common, not in any subdirectory.
Also, it would be hard to guarantee that there is no log4j.properties anywhere in a place where Tomcat can see it such as an arbitrary jar file in common/lib or shared/lib. You never know.
Ah, correct, there was one JAR file (emphasis on "was") that contained a log4j.properties file (all my jar files contain one) and I removed it. Forcefully. Was not very pretty. So now it can't find one anymore, see the "[null]" thing log4j is reporting.
That's why I recommend against counting on auto-configuration. It is there for convenience, but doesn't always provide what you need. Anyway...
But I like it! ;-) It allows me the have a config setup as developer and deploy that, but have a system manager override it. Or if I have a jar which has log4j and it will find at least some configuration file.
Now, if I start Tomcat with "-Dlog4j.debug=true", I get NO debug output nor is my log4j.properties loaded, but I do not get log4j error messages about needing a log4j.properties (so it did find one), and there is log4j output being generated...
Why don't I get debug output?
That's a bit odd, I must say.
Ah, I must concur there...
server/lib is not a place to put stuff for your webapp to see. Even much of Tomcat's common stuff can't see server/lib. for instance, common/lib can't see server/lib, although the converse is true. Personally, I always put log4j.jar in common/lib and a log4j.xml (for server logging only) in common/classes. I then have the choice of putting log4j.jar and log4j.xml in each webapp or just have log4j.xml in each webapp, do manual configuration, and use a repository selector to use the common log4j.jar in common/lib.
Hm. Point made. I've writting some addons to Tomcat and it got a kind of habbit to put stuff in "server".
Why isn't it looking into my web-inf/classes?
It should, I'm not sure why it isn't. Webapps look in the WebappClassLoader first before looking in a parent classloader (note that this is opposite to normal Java2 classloading behavior where the parent is usually searched first). BTW, are you starting Tomcat up using the standard startup scripts or starting Tomcat as a service?
Yikes! Noooooo, normal script, so I have a good control of what's in and what's out and what JDK is used. (The same Tomcat version sometimes is started under JDK1.3, sometimes under JDK1.4.)
The best policy here is to clean up your system classpath. Mine is a single period and nothing else which avoids this whole issue whether or not I start via scripts or as a service.
Yup. Mine is too.
This classloader stuff can drive one insane.
Oh, is that what it is, I was wondering why I was hanging upside down from our kitchen lamp.
Thanks! As soons as I've got the laptop reinstalled, I'll try all this.
Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
