Next Log4cxx Major release thoughts

[rm5248]

Whenever we do a new major release of Log4cxx(also breaking ABI compatibility), what should we do? My current thoughts are as follows:

1. Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++
2. What should the minimum C++ version be? C++20 includes std::source_location, while C++23 includes std::stacktrace
3. add constexpr to a bunch of functions? I've been reading up on how constexpr works, so perhaps some more thoughts on this later
4. Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?
5. Do we have any areas in the code where performance is a known problem, and could a redesign help to eliminate performance issues?
6. What about C++ modules? Are traditional headers ever going away?

Features to definitely keep:

1. Static declaration of loggers. While this does lead to undefined behavior at times(generally when exiting), being able to statically declare a logger is very important to me.

What other thoughts do people have?

In terms of timelines, I wouldn't expect a new version to be done before the end of 2026, so this is a pretty long timeline.

[swebb2066]

Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++

I do not believe it is yet possible to remove the APR dependency as it provides essential functionality (e.g. apr_file_write, apr_proc_create) that is not yet in the C++ standard library.

Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?

I suggest changing the LOG4CXX_DEBUG family of macros to require logged values be copy-constructible/move-constructible. This would allow us to implement the equivalent to "asynchronous loggers" that is already in Log4j2, and for users to see performance benefits without any code change. The LoggingEvent would need to hold a std::vector<std::function<void(MessageBuffer&)>> or similar.

[rm5248]

Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++

I do not believe it is yet possible to remove the APR dependency as it provides essential functionality (e.g. apr_file_write, apr_proc_create) that is not yet in the C++ standard library.

Is there a reason that we should continue to use the APR functions? I haven't looked closely, but I think for the most part the APR functions are wrappers around fopen and other C functions.

Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?

I suggest changing the LOG4CXX_DEBUG family of macros to require logged values be copy-constructible/move-constructible. This would allow us to implement the equivalent to "asynchronous loggers" that is already in Log4j2, and for users to see performance benefits without any code change. The LoggingEvent would need to hold a std::vector<std::function<void(MessageBuffer&)>> or similar.

I like that thought.

I haven't messed around with it yet, but if we want to support newer C++ standards, we could automatically create std::backtrace objects, and use std::source_location instead of the custom type that exists today. The problem with the backtrace is that I don't have any ideas on how to make it easy without a macro at the moment. The only thing I can think of is to do a fluent interface like:

logger.debug("message").withLocation().withBacktrace();

But I prefer having the macros, since that can expand into code better. The above example is similar to what flogger does.

[rm5248]

I messed around a bit with a new possible way to log stuff tonight: https://github.com/rm5248/cxx-logger-testing/tree/main

I have no idea if it is faster or not; a lot of work would have to be done in order to see what performance hit(if any) this would cause. I expect that there could still be some optimizations to do.

Some parts that I consider important:

• it uses no macros, instead using std::source_location for the source file location
• Because of the above, C++20 is required
• you need a modern version of GCC, since it only gained std::format support fairly recently
• the way to log is very easy: l.debug_fmt("hi {}", "todd")();

Feedback/thoughts would be good.

[swebb2066]

a new possible way to log stuff

Log4cxx must not go down this path. Backward compatibility of Log4cxx is its critical contribution. Given the millions of lines of source code already out there using it, maintaining source code compatibility should be the primary objective.

There are already lots of example "new way to log stuff" projects out there.

Also note that even Rust uses macros for logging.

[rm5248]

I'm not advocating breaking any of the logging macros, this was more of an experiment to ask "what could a logging framework look like." I think that this could be useful for a common logging API, similar to how SLF4J or Log4j2-API works. A logging framework would do the actual logging. Besides, what I've done could also just be used to extend the current logger class.

Are you more concerned with API or ABI compatibility? If/when compatibility is broken, we would want to be deliberate about it.

[swebb2066]

I'm not advocating breaking any of the logging macros

Good to hear.

a common logging API, similar to how SLF4J or Log4j2-API

That is above my pay grade. Even Herb Suttor, when asked to include logging in his new experimental C++ 'syntax 2' (Cpp2) did not want to take that on. He pushed the questioner to use existing C++1 code libraries (spdlog)

[swebb2066]

I had previously thought we could provide users performance benefits without any code change by introducing asynchronous loggers as the default. I have since realised this would not be a good idea because:

1. Buffered asynchronous logging creates confusion during development as the log file may not contain the most recent logging events (when the debugger stops the application or std::terminate is called)
2. The LOG4CXX_XXXX_ASYNC macros introduce significant code bloat (approx 200 bytes per log request) compared to LOG4CXX_XXXX macros.

Given I do not see a technical need for a new ABI arrizing soon, one option we have would be to relabel the 1.6 features as 2.0 and bump the ABI version now.

Thoughts?

[rm5248]

My preference would be to do a 1.6 release, and then bump the version, aiming to have a new version sometime next year(I'm thinking either May or August depending on how things go). That would fix some outstanding issues while also giving us some time to do any other ABI changes needed. I do still want to do some more changes to try and make APR optional, but I haven't spent much time on log4cxx lately.

[coldtobi]

introducing asynchronous loggers as the default.

note this might be a backward-incompatible change, at least on Linux: if the sync thread is spawned automatically that will break applications using fork() and logging before fork().