I'm using log4j for logging in my JRuby on Rails application. Every single time I push the application out, logs are getting appended to different end destinations. Sometimes it's catalina.out. sometimes it's localhost-date.log. sometimes it's catalina-date.log.
I'm not really sure why it's not the same every single time.
what are some things I can check as to why logs are so unreliable in my environment?
This is pretty weird indeed - are you by chance using Apache Commons Logging as well?
It's just a short in the dark, but every time I experience something weird with log4j and/or Commons Logging I immediately recall and revisit the well documented problems with the latter specifically (see Think again before adopting the commons-logging API, or the even more comprehensive version Taxonomy of class loader problems encountered when using Jakarta Commons Logging), concisely summarized in delfuego's answer for log4j and the thread context classloader:
You appear to have stumbled upon the major problem with log4j (and the Apache Commons Logging library), namely that they have a ridiculously hard time discovering and interacting with the right classloaders as they're being used.
Given the very nature of the classloader issue, I could imagine it tripping your problem as well, i.e. depending on which classloader currently ended up wiring in your logging, it might use a different logging properties search path and respective defaults as well, see Why can't log4j find my properties file in a J2EE or WAR application?:
The short answer: the log4j classes and the properties file are not within the scope of the same classloader.
The long answer (and what to do about it): J2EE or Servlet containers utilize Java's class loading system. Sun changed the way classloading works with the release of Java 2. In Java 2, classloaders are arranged in a hierarchial parent-child relationship. When a child classloader needs to find a class or a resource, it first delegates the request to the parent. [...]
The mentioned problems are usually easy to remedy by switching to Simple Logging Facade for Java (SLF4J) indeed (which happens to have the same author as log4j btw., Ceki Gülcü), as likewise suggested by delfuego:
[...] the take-home message is that one of the primary driving forces for the new logging framework SL4J was to eliminate these issues entirely. You might want to swap it in and see if your life is made any easier.
Finally, John's (as of today unresolved) adventure with Logging with log4j on tomcat jruby-rack for a Rails 3 application seems to hint on respective issues and a possible solution via SL4J as well.
Good luck!
