Re: [log4cxx] Stacktrace support

[Stephen Webb]

I am not able to think of any use-case where filtering the stacktrace data
would be useful.

It is already possible to put the stacktrace into the log using C++ streams
- boost stacktrace provides

std::basic_ostream< CharT, TraitsT > &
  operator<<(std::basic_ostream< CharT, TraitsT > & os,
 const basic_stacktrace
<
Allocator > & bt);


On Fri, Dec 16, 2022 at 2:39 PM Robert Middleton 
wrote:

> I've been working on adding in stacktrace support to Log4cxx using
> Boost stacktrace.  One of my objectives with this is to make this
> entirely optional, such that both Log4cxx needs to have support for
> Boost stacktrace and the client code needs to enable it, so by default
> a stacktrace is not collected.
>
> In order to do this, I've somewhat simplified the logger methods, so
> where it was two methods:
> void forcedLog(const LevelPtr& level,
> const std::string& message,
> const log4cxx::spi::LocationInfo& location);
> void forcedLog(const LevelPtr& level,
> const std::string& message);
>
> I've converted it into one method:
> void forcedLog(const LevelPtr& level,
> const std::string& message,
> const log4cxx::spi::LocationInfo& location =
> log4cxx::spi::LocationInfo::getLocationUnavailable(),
> const log4cxx::OptionalLogParams& optionalParams =
> log4cxx::OptionalLogParams()) const;
>
> The 'optional params' here being effectively just a map that we can
> throw more pointers into if we need to add more information at a later
> point.
>
> This seems like the most reasonable way to prevent a method
> explosion(adding more method overloads).
>
> I'm not sure if this is the best way to go though and was wondering if
> anybody had any better ideas.  There are a few options that I was
> thinking of:
> 1. Throw the stacktrace string into the (already-existing) MDC and
> letting users do something like %X{stacktrace}  to print the value
> 2. Add more method overloads to the Logger class to take in the
> stacktrace(when available) so the logging event has a copy of the
> stacktrace
> 3. Use a map to pass optional void* pointers to the Logger, so that we
> avoid an explosion of overridden methods while still keeping a copy of
> the stacktrace
>
> I'm wondering if I'm overthinking this - my original concern was to
> have a copy of the stacktrace so that you could eventually do some
> kind of filtering with the stacktrace data, but upon thinking about it
> more I don't know when you would ever have to do that, especially
> since the stacktrace is really only useful if you have a debug build.
> Am I right in overthinking this?  Is there something much simpler that
> I'm missing?
>
> -Robert Middleton
>

[log4cxx] Stacktrace support

[Robert Middleton]

I've been working on adding in stacktrace support to Log4cxx using
Boost stacktrace.  One of my objectives with this is to make this
entirely optional, such that both Log4cxx needs to have support for
Boost stacktrace and the client code needs to enable it, so by default
a stacktrace is not collected.

In order to do this, I've somewhat simplified the logger methods, so
where it was two methods:
void forcedLog(const LevelPtr& level,
const std::string& message,
const log4cxx::spi::LocationInfo& location);
void forcedLog(const LevelPtr& level,
const std::string& message);

I've converted it into one method:
void forcedLog(const LevelPtr& level,
const std::string& message,
const log4cxx::spi::LocationInfo& location =
log4cxx::spi::LocationInfo::getLocationUnavailable(),
const log4cxx::OptionalLogParams& optionalParams =
log4cxx::OptionalLogParams()) const;

The 'optional params' here being effectively just a map that we can
throw more pointers into if we need to add more information at a later
point.

This seems like the most reasonable way to prevent a method
explosion(adding more method overloads).

I'm not sure if this is the best way to go though and was wondering if
anybody had any better ideas.  There are a few options that I was
thinking of:
1. Throw the stacktrace string into the (already-existing) MDC and
letting users do something like %X{stacktrace}  to print the value
2. Add more method overloads to the Logger class to take in the
stacktrace(when available) so the logging event has a copy of the
stacktrace
3. Use a map to pass optional void* pointers to the Logger, so that we
avoid an explosion of overridden methods while still keeping a copy of
the stacktrace

I'm wondering if I'm overthinking this - my original concern was to
have a copy of the stacktrace so that you could eventually do some
kind of filtering with the stacktrace data, but upon thinking about it
more I don't know when you would ever have to do that, especially
since the stacktrace is really only useful if you have a debug build.
Am I right in overthinking this?  Is there something much simpler that
I'm missing?

-Robert Middleton