You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Hein Meling <me...@item.ntnu.no> on 2002/08/01 15:10:00 UTC
RE: feature request: logging a stack trace
I knew about the location info stuff, but this applies to all messages
logged, and that will clearly affect performance even more than doing it
for just a few log messages. Also, the location info does not include
the entire stack trace, thus making it difficult to trace the entire
chain of method calls... The problem with my approach is that it is not
configurable; you have to recompile to add stack trace information to a
particular place in your code. But I still think it is useful, for
debugging purposes mainly.
Ciao,
Hein
On Tue, 2002-07-30 at 22:34, Mark Womack wrote:
> Logging events also support something called location info. It records
> where the event was logged from and can be displayed via the PatternLayout
> (see the javadoc for details). It displays the stack from where the logging
> event was recorded. All you have to do is use the correct conversion
> character in the PatternLayout.
>
> But it will affect performance if displayed with every logging message (as
> will your code below, I believe).
>
> -Mark
>
> > -----Original Message-----
> > From: Hein Meling [mailto:meling@item.ntnu.no]
> > Sent: Tuesday, July 30, 2002 12:48 PM
> > To: Log4J Users List
> > Subject: feature request: logging a stack trace
> >
> >
> > hi.
> >
> > sorry if this is not the right place for this kind of request, but i
> > don't want to subscribe to the developers list.
> >
> > anyway, sometimes it may be very useful to log a stack
> > trace, even if
> > there was no exception, in order to determine from where a method is
> > being called. is this idea something that could be interesting to add
> > to the Logger (or Category) class in Log4j? That is a method like:
> > logStackTrace(), or whatever...
> >
> > my implementation (residing in a class called Debug) is
> > very rough so,
> > it needs a bit of cleaning up to fit well into log4j:
> >
> >
> > public static void logStackTrace(org.apache.log4j.Logger log)
> > {
> > try {
> > throw new Exception();
> > } catch (Exception e) {
> > StringWriter swriter = new StringWriter();
> > e.printStackTrace(new PrintWriter(swriter));
> > log.debug(swriter.toString());
> > }
> > }
> >
> >
> > comments?
> >
> > ciao,
> > - hein
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: renderes in context
Posted by Hein Meling <me...@item.ntnu.no>.
Maybe I don't understand your question, but wouldn't this do what you
want:
log.info("Context information... data:" + renderableObject);
???
Cheers,
Hein
On Fri, 2002-08-02 at 14:39, Barry Kaplan wrote:
> We've just started to use renderers, as it makes things a bit cleaner.
> However, we often need to log the same object (eg, the state of a newly
> creatred entity) in several different contexts. What I'm looking for is
> something functionaly simular to:
>
> Logger.info(Object object)
> Logger.info(String messagePrefix, Object object)
> Logger.info(Object object, Throwable)
> Logger.info(String messagePrefix, Object object, Throwable)
>
> Where the renderer is used for 'object', but the log message it produces
> is preceeded by 'mesagePrefix'.
>
> I could [almost] achive what I need with:
>
> log.info("Context information... data:");
> log.info(renderableObject);
>
> But that creates two log statements, and I only want one (especially
> since we have many threads and processes pumping messages into the log file.
>
> -bk
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
renderes in context
Posted by Barry Kaplan <bk...@abwg.com>.
We've just started to use renderers, as it makes things a bit cleaner.
However, we often need to log the same object (eg, the state of a newly
creatred entity) in several different contexts. What I'm looking for is
something functionaly simular to:
Logger.info(Object object)
Logger.info(String messagePrefix, Object object)
Logger.info(Object object, Throwable)
Logger.info(String messagePrefix, Object object, Throwable)
Where the renderer is used for 'object', but the log message it produces
is preceeded by 'mesagePrefix'.
I could [almost] achive what I need with:
log.info("Context information... data:");
log.info(renderableObject);
But that creates two log statements, and I only want one (especially
since we have many threads and processes pumping messages into the log file.
-bk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: feature request: logging a stack trace
Posted by Ceki Gülcü <ce...@qos.ch>.
Hmm, you are not aware of the debug(Object, Throwable) method in
Logger class, are you? You can just write:
log.debug("genereting stack trace", new Exception());
At 15:10 01.08.2002 +0200, you wrote:
> I knew about the location info stuff, but this applies to all messages
>logged, and that will clearly affect performance even more than doing it
>for just a few log messages. Also, the location info does not include
>the entire stack trace, thus making it difficult to trace the entire
>chain of method calls... The problem with my approach is that it is not
>configurable; you have to recompile to add stack trace information to a
>particular place in your code. But I still think it is useful, for
>debugging purposes mainly.
>
>Ciao,
> Hein
>
>On Tue, 2002-07-30 at 22:34, Mark Womack wrote:
> > Logging events also support something called location info. It records
> > where the event was logged from and can be displayed via the PatternLayout
> > (see the javadoc for details). It displays the stack from where the
> logging
> > event was recorded. All you have to do is use the correct conversion
> > character in the PatternLayout.
> >
> > But it will affect performance if displayed with every logging message (as
> > will your code below, I believe).
> >
> > -Mark
> >
> > > -----Original Message-----
> > > From: Hein Meling [mailto:meling@item.ntnu.no]
> > > Sent: Tuesday, July 30, 2002 12:48 PM
> > > To: Log4J Users List
> > > Subject: feature request: logging a stack trace
> > >
> > >
> > > hi.
> > >
> > > sorry if this is not the right place for this kind of request, but i
> > > don't want to subscribe to the developers list.
> > >
> > > anyway, sometimes it may be very useful to log a stack
> > > trace, even if
> > > there was no exception, in order to determine from where a method is
> > > being called. is this idea something that could be interesting to add
> > > to the Logger (or Category) class in Log4j? That is a method like:
> > > logStackTrace(), or whatever...
> > >
> > > my implementation (residing in a class called Debug) is
> > > very rough so,
> > > it needs a bit of cleaning up to fit well into log4j:
> > >
> > >
> > > public static void logStackTrace(org.apache.log4j.Logger log)
> > > {
> > > try {
> > > throw new Exception();
> > > } catch (Exception e) {
> > > StringWriter swriter = new StringWriter();
> > > e.printStackTrace(new PrintWriter(swriter));
> > > log.debug(swriter.toString());
> > > }
> > > }
> > >
> > >
> > > comments?
> > >
> > > ciao,
> > > - hein
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> > --
> > To unsubscribe,
> e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>