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 <boa...@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 <garydgreg...@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 <boa...@gmail.com>
>
