You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2006/07/31 19:09:33 UTC
DO NOT REPLY [Bug 40145] New: - PatternLayout - %r doesn't do what the documentation says.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40145>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40145
Summary: PatternLayout - %r doesn't do what the documentation
says.
Product: Log4j
Version: 1.2
Platform: All
OS/Version: other
Status: NEW
Severity: minor
Priority: P2
Component: Layout
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: mark.atwell@jpmorgan.com
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.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: DO NOT REPLY [Bug 40145] New: - PatternLayout - %r doesn't do what the documentation says.
Posted by Ron Grabowski <ro...@yahoo.com>.
This is how log4net dealt with the issue:
http://issues.apache.org/jira/browse/LOG4NET-50
"
Rather than using the Process.StartTime the current time is captured
when the log4net library is loaded (when LogManager is initialised) and
this is used as the start time.
"
--- bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=40145>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40145
>
> Summary: PatternLayout - %r doesn't do what the
> documentation
> says.
> Product: Log4j
> Version: 1.2
> Platform: All
> OS/Version: other
> Status: NEW
> Severity: minor
> Priority: P2
> Component: Layout
> AssignedTo: log4j-dev@logging.apache.org
> ReportedBy: mark.atwell@jpmorgan.com
>
>
> 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.
>
> --
> Configure bugmail:
> http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 40145] - PatternLayout - %r doesn't do what the documentation says.
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40145>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40145
carnold@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From carnold@apache.org 2006-08-02 03:34 -------
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).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org