| Summary: | PatternLayout - %r doesn't do what the documentation says. | ||
|---|---|---|---|
| Product: | Log4j - Now in Jira | Reporter: | Mark Atwell <mark.atwell> |
| Component: | Layout | Assignee: | log4j-dev <log4j-dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | ||
| Priority: | P2 | ||
| Version: | 1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | other | ||
log4cxx captures the time of the APR initializer which should occur during static initialization so it should be very close to application start time. At this point, the safest thing to do with log4j 1.2 would be to change the documentation to match the established behavior which I have done for both log4j 1.2 and 1.3. However, if someone wants to submit a patch for log4j 1.3 that implements the previously documented behavior, I'd be open to committing it. Commited in rev 427875 and 427876 (1.2 and trunk, respectively). |
According to the Javadocs: %r - Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event. In practice the initial time is actually initialised from when the PatternLayout class is loaded and the static initialisers are fired. Consider the following rather contrived and paraphrased example: public class MyClass { static final Logger logger = Logger.getLogger(MyClass.class); public static void main(String[] args) throws Exception { BasicConfigurator.configure(); Thread.sleep(10 * 1000); logger.info("Hello, World!"); } } The time reported at Hello, World is actually very close to zero. AFAIK it seems to be practically impossible to know the app/JVM launch-time, nonetheless it could be better. Solutions I guess would be for the configuration call or, probably better, one of the Logger.getLogger() calls initialised the time or forces load of the PatternLayout class-load? A workaround is to log something early and of course many apps do this so it isn't a noted problem. In practice this is probably not unique to any platform or possibly even version of Log4J. Do any of the other implementations suffer from the same problem.