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
<https://www.boost.org/doc/libs/develop/doc/html/boost/stacktrace/basic_stacktrace.html><
Allocator > & bt);
On Fri, Dec 16, 2022 at 2:39 PM Robert Middleton <rmiddle...@apache.org>
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
>
