Hey all,
I'd like to propose some new features/updates for log4cxx, if there's
interest. A number of these are rather large changes, so it probably
doesn't make sense to work on them until there's a known-good release, as
they would likely break both API and ABI compatibility.
Big Changes:
1. Using std::shared_ptr(LOG4CXX-486). I did a proof-of-concept about
three years ago at this point, but I never did a patch/pull request as this
would change quite a lot. I think as a result of this I also removed the
mutex implementation and replaced with std::mutex.
2. Removal of most APR usage. Since C++11 we have mutexes, threads,
condition_variable, time functions, atomic functions, etc. There's still
some things beyond what I've mentioned that APR provides, but I could see a
potential use-case where the core library doesn't depend on APR, although
it would have limited functionality at that point.
3. Removal of maven for site generation. While it does provide a
consistent feel with log4j2, it seems like it is the source of a large
number of problems(releasing, building, etc.). It seems to me that the
best way would be to use doxygen to generate the site instead; we can use
markdown to create documentation pages instead of the doxia apt format.
The other advantage to this would be that it also means that only one site
is generated that contains both normal documentation as well as the API
documentation at the same time.
4. ABI compatibility. It would be good to keep all instance variables
in a private data member, so that they can be added/removed without
breaking the ABI. This may require some other changes to the API though,
as it would probably break some inline methods(this pattern is commonly
called a pimpl).
Medium changes:
1. Adding in libfmt to format arguments[1]. I did a proof-of-concept
earlier today by adding a new macro earlier today that looks like the
following: LOG4CXX_ERROR_F( logger, "hi {}", "Robert" ); Since this
library provides a bunch of nice formatting functions it should make
logging much clearer and more like log4j2.
2. Remove the autotools build - it seems to me that the CMake tooling
has successfully worked, and is fully cross-platform at this point. Is
there a particular reason to keep it around still?
3. Support for log4j2-style XML/JSON/YAML documents. The information
for log4j(1) style documents is harder to find now, so it seems to me that
having commonality with log4j2 moving forward would be a good idea for
consistency.
4. Add a new library to allow logging from Qt-based applications, e.g.
log4cxx-qt. I've done this before using qInstallMessageHandler[2], so it's
not too difficult to do. Also having some default appenders for e.g.
QString is useful, so that when I'm logging I don't need to do
.toStdString() all the time on the QStrings.
Going through the currently open issues in JIRA, there's also a large
number that are either so old that they don't make much sense, or may have
been fixed already. Would it make sense to go through them at some point?
That's probably not something that I can do alone, but I can help to go
through them.
-Robert Middleton
[1]: https://fmt.dev/latest/index.html
[2]: https://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler
