[log4j] A API or pattern for better stack trace logging

[Gary Gregory <ga...@gmail.com>]

Hi All:

In our server, there are certain kinds of exceptions that are caught that I
want processed in a special manner. One example of this is for various
kinds of time outs that surface as exceptions. Sometimes comms time out,
requests may be resubmitted, and in general all is well.

For day-to-day logging, I only want to show the _message_ of exception as
an informative log event (INFO). I do not want to log the stack trace in
this mode, as this alarms users to no end.

When I am in trouble shooting mode, I do want to see the exception's stack
trace logged, say, at the DEBUG (or TRACE) level.

Currently, I have some selective call sites with ugly logic to handle this
kind of logging. The simplest way to handle this is with some double
logging:

logger.info("foo: {}}, exception.toString());
logger.debug(exception);

This is obviously ugly and a pain to maintain.

Can you all think of how this could be addressed, either at the API site or
at the _pattern_ definition site? Maybe with a new option in the pattern?

Gary

Re: [log4j] A API or pattern for better stack trace logging

[Matt Sicker <bo...@gmail.com>]

Oh cool, I didn’t even see pattern selectors! Definitely the way to go here.

On Sun, Aug 12, 2018 at 12:19, Ralph Goers <ra...@dslextreme.com>
wrote:

> Also, if you want to do something more complex you can implement your own
> PatternSelector or use the ScriptPatternSelect.
>
> Ralph
>
> > On Aug 12, 2018, at 8:47 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > Hi All:
> >
> > In our server, there are certain kinds of exceptions that are caught
> that I
> > want processed in a special manner. One example of this is for various
> > kinds of time outs that surface as exceptions. Sometimes comms time out,
> > requests may be resubmitted, and in general all is well.
> >
> > For day-to-day logging, I only want to show the _message_ of exception as
> > an informative log event (INFO). I do not want to log the stack trace in
> > this mode, as this alarms users to no end.
> >
> > When I am in trouble shooting mode, I do want to see the exception's
> stack
> > trace logged, say, at the DEBUG (or TRACE) level.
> >
> > Currently, I have some selective call sites with ugly logic to handle
> this
> > kind of logging. The simplest way to handle this is with some double
> > logging:
> >
> > logger.info("foo: {}}, exception.toString());
> > logger.debug(exception);
> >
> > This is obviously ugly and a pain to maintain.
> >
> > Can you all think of how this could be addressed, either at the API site
> or
> > at the _pattern_ definition site? Maybe with a new option in the pattern?
> >
> > Gary
>
>
> --
Matt Sicker <bo...@gmail.com>

Re: [log4j] A API or pattern for better stack trace logging

[Ralph Goers <ra...@dslextreme.com>]

Also, if you want to do something more complex you can implement your own PatternSelector or use the ScriptPatternSelect.

Ralph

> On Aug 12, 2018, at 8:47 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Hi All:
> 
> In our server, there are certain kinds of exceptions that are caught that I
> want processed in a special manner. One example of this is for various
> kinds of time outs that surface as exceptions. Sometimes comms time out,
> requests may be resubmitted, and in general all is well.
> 
> For day-to-day logging, I only want to show the _message_ of exception as
> an informative log event (INFO). I do not want to log the stack trace in
> this mode, as this alarms users to no end.
> 
> When I am in trouble shooting mode, I do want to see the exception's stack
> trace logged, say, at the DEBUG (or TRACE) level.
> 
> Currently, I have some selective call sites with ugly logic to handle this
> kind of logging. The simplest way to handle this is with some double
> logging:
> 
> logger.info("foo: {}}, exception.toString());
> logger.debug(exception);
> 
> This is obviously ugly and a pain to maintain.
> 
> Can you all think of how this could be addressed, either at the API site or
> at the _pattern_ definition site? Maybe with a new option in the pattern?
> 
> Gary

Re: [log4j] A API or pattern for better stack trace logging

[Gary Gregory <ga...@gmail.com>]

So you are saying the code would look like this:

logger.info(MARKER_EX, "foo: {}", exception);

What I am not clear on is whether the param 'exception' is 'consumed' by
the parameter marker and no stack trace is logged, or, if the exception is
logged no matter what since the _last_ param is a kind of exception.

Aside from that, your are suggesting, that a rewrite appender can:
- Suppress the exception logging when the marker is MARKER_EX and the
logger is at INFO (writing a new rewrite policy)
- Change the level to DEBUG when the marker is MARKER_EX and the logger is
at DEBUG (using the LoggerNameLevelRewritePolicy)
- Combine the two above by writing a new "CompositeRewritePolicy" which
seems like a nice addition to Log4j.

?

Gary

On Sun, Aug 12, 2018 at 9:58 AM Matt Sicker <bo...@gmail.com> wrote:

> If you used a marker, you could make a separate pattern for that marker via
> filters where the marked one shows brief exceptions and the other shows
> full stacktraces. This might even be possible using the rewrite appender
> from what I'm reading there.
>
> On Sun, 12 Aug 2018 at 10:47, Gary Gregory <ga...@gmail.com> wrote:
>
> > Hi All:
> >
> > In our server, there are certain kinds of exceptions that are caught
> that I
> > want processed in a special manner. One example of this is for various
> > kinds of time outs that surface as exceptions. Sometimes comms time out,
> > requests may be resubmitted, and in general all is well.
> >
> > For day-to-day logging, I only want to show the _message_ of exception as
> > an informative log event (INFO). I do not want to log the stack trace in
> > this mode, as this alarms users to no end.
> >
> > When I am in trouble shooting mode, I do want to see the exception's
> stack
> > trace logged, say, at the DEBUG (or TRACE) level.
> >
> > Currently, I have some selective call sites with ugly logic to handle
> this
> > kind of logging. The simplest way to handle this is with some double
> > logging:
> >
> > logger.info("foo: {}}, exception.toString());
> > logger.debug(exception);
> >
> > This is obviously ugly and a pain to maintain.
> >
> > Can you all think of how this could be addressed, either at the API site
> or
> > at the _pattern_ definition site? Maybe with a new option in the pattern?
> >
> > Gary
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: [log4j] A API or pattern for better stack trace logging

[Matt Sicker <bo...@gmail.com>]

If you used a marker, you could make a separate pattern for that marker via
filters where the marked one shows brief exceptions and the other shows
full stacktraces. This might even be possible using the rewrite appender
from what I'm reading there.

On Sun, 12 Aug 2018 at 10:47, Gary Gregory <ga...@gmail.com> wrote:

> Hi All:
>
> In our server, there are certain kinds of exceptions that are caught that I
> want processed in a special manner. One example of this is for various
> kinds of time outs that surface as exceptions. Sometimes comms time out,
> requests may be resubmitted, and in general all is well.
>
> For day-to-day logging, I only want to show the _message_ of exception as
> an informative log event (INFO). I do not want to log the stack trace in
> this mode, as this alarms users to no end.
>
> When I am in trouble shooting mode, I do want to see the exception's stack
> trace logged, say, at the DEBUG (or TRACE) level.
>
> Currently, I have some selective call sites with ugly logic to handle this
> kind of logging. The simplest way to handle this is with some double
> logging:
>
> logger.info("foo: {}}, exception.toString());
> logger.debug(exception);
>
> This is obviously ugly and a pain to maintain.
>
> Can you all think of how this could be addressed, either at the API site or
> at the _pattern_ definition site? Maybe with a new option in the pattern?
>
> Gary
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [log4j] A API or pattern for better stack trace logging

[Ralph Goers <ra...@dslextreme.com>]

1. Define a Marker

public static final Marker EXCEPTION_MESSAGE = MarkerManager.getMarker(“EXCEPTION_MESSAGE”);

2. Use the Marker

logger.info(EXCEPTION_MESSAGE, execution);

3. Use the MarkerPatternSelector

<Console name="Console" target="SYSTEM_OUT">
    <PatternLayout>
        <MarkerPatternSelector defaultPattern="[%-5level] %msg%n">
            <PatternMatch key=“EXCEPTION_MESSAGE" pattern="[%-5level] - %msg %throwable{short.message}%n"/>
        </MarkerPatternSelector>
    </PatternLayout>
</Console>

Ralph


> On Aug 12, 2018, at 8:47 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Hi All:
> 
> In our server, there are certain kinds of exceptions that are caught that I
> want processed in a special manner. One example of this is for various
> kinds of time outs that surface as exceptions. Sometimes comms time out,
> requests may be resubmitted, and in general all is well.
> 
> For day-to-day logging, I only want to show the _message_ of exception as
> an informative log event (INFO). I do not want to log the stack trace in
> this mode, as this alarms users to no end.
> 
> When I am in trouble shooting mode, I do want to see the exception's stack
> trace logged, say, at the DEBUG (or TRACE) level.
> 
> Currently, I have some selective call sites with ugly logic to handle this
> kind of logging. The simplest way to handle this is with some double
> logging:
> 
> logger.info("foo: {}}, exception.toString());
> logger.debug(exception);
> 
> This is obviously ugly and a pain to maintain.
> 
> Can you all think of how this could be addressed, either at the API site or
> at the _pattern_ definition site? Maybe with a new option in the pattern?
> 
> Gary