Bug 40145 - PatternLayout - %r doesn't do what the documentation says.
Summary: PatternLayout - %r doesn't do what the documentation says.
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Layout (show other bugs)
Version: 1.2
Hardware: All other
: P2 minor
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2006-07-31 17:09 UTC by Mark Atwell
Modified: 2006-08-01 20:34 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Atwell 2006-07-31 17:09:32 UTC
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 

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

  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.
Comment 1 Curt Arnold 2006-08-02 03:34:08 UTC
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).