Log4Qt, a Log4j-shaped logger for Qt applications

A Log4j port, not a fresh logging design

Log4Qt is described as a C++ port of the Apache Software Foundation Log4j package using the Qt Framework, and it is intended to be used by both open source and commercial Qt projects. The name and the API shape are the point: a developer who has configured Log4j in a Java service can configure this in a Qt application with the same concepts and largely the same class names.

That inheritance shows up in the configuration examples in the project documentation. The appender type in the sample configuration is `org.apache.log4j.ConsoleAppender`, and the layout is `org.apache.log4j.TTCCLayout`, which is a Log4j class name rather than a Log4Qt one. The legacy namespace is accepted alongside the Log4Qt namespace and short aliases such as `Console` and `TTCCLayout`.

For a C++ team, that is either the main reason to use the library or the main reason to skip it. If your organisation already has Log4j configuration, alerting rules, log shipping infrastructure and runbooks built around that model, adopting Log4Qt means the operational side transfers unchanged. If you would rather have a logger that fits the Qt ecosystem's own idioms, the Log4j heritage is baggage.

There is also a lineage worth knowing, because it explains the repository's shape. The documentation records that this repository is a clone of the Log4Qt repository from Gitorious, which was itself a clone of the original SourceForge project, and points at the original log4qt project site. The project has been moved between forges, and the current home is the GitHub one under the MEONMedical organisation.

The audience is a C++ developer working on a desktop or embedded-style Qt application who wants structured, configurable logging and would rather not write their own appenders.

Appenders and layouts, the Log4j vocabulary in C++

The feature list in the project documentation is where the practical scope shows, and it is a long one.

There is a ColorConsoleAppender, which renders colorised messages by escape sequence and writes them to the console. There is a DatabaseAppender that appends log events into a SQL table, with a matching DatabaseLayout that puts the event into the table columns. A Telnet appender writes log events to telnet clients, which is an old-fashioned but still useful remote tail. A SignalAppender emits a signal when a log event happens, so a Qt application can react to logging rather than only print it. A MainThreadAppender is a proxy appender for sending log messages through the event loop, which matters when a worker thread's log line has to be delivered on the GUI thread. A LogStream appends qDebug()-style log messages, and a Binary logger and a Windows Debug Console Appender cover the cases where plain text is wrong.

For files, there is a DailyRollingFileAppender that generates a logfile for each day by adding the current date to the filename, an XMLLayout to support Apache Chainsaw, and a SimpleTimeLayout with the format dd.MM.yyyy hh:mm [Thread] Level Logger Message, which is a European date order and includes the thread, so it is directly aimed at desktop applications where several threads log at once.

The 2.0 addition worth singling out is the rolling file behaviour. The documentation describes pluggable TriggeringPolicy and RolloverStrategy for the RollingFileAppender in log4j2 style: size-based, time-based, cron-based and on-startup triggering policies, with composable OR-combination and a fixed-window numbered rollover strategy. That is the part Log4j 1.x users always struggled with, because rollover was hardcoded, and it is the most likely reason to look at the 2.0 line.

All of this is a lot of surface area, and it is the surface area of a logging framework rather than of a library with one job. Every appender is a place where a mistake becomes an outage.

Three configuration formats and a priority order

Log4Qt 2.0 added JSON configuration and XML configuration alongside the classic `.properties` format, and the rules for using them are specific enough to be worth reading carefully.

The JSON format is described as `log4qt.json` and mirrors the properties structure. Nested objects produce dot-separated property keys, and the `type` key sets the class for the parent object, meaning the appender, layout or filter, and explicitly not `class` or `@class`. The value accepts the legacy `org.apache.log4j.*` names, the `Log4Qt::*` names, or short aliases.

{
    "log4j": {
        "rootLogger": "DEBUG, console",
        "appender": {
            "console": {
                "type": "org.apache.log4j.ConsoleAppender",
                "target": "STDOUT_TARGET",
                "layout": {
                    "type": "org.apache.log4j.TTCCLayout",
                    "dateFormat": "ISO8601"
                }
            }
        },
        "logger": {
            "MyApp": "ERROR, console"
        },
        "additivity": {
            "MyApp": "false"
        }
    }
}

The XML variant follows the same idea with elements instead of objects. Nested elements produce dot-separated property keys, and a `<type>` element sets the class for the parent element, not a `class` attribute as in Log4j's own XML, although the documentation notes that attributes flatten to child properties so `type="..."` as an attribute also works while `class="..."` does not.

The priority order is stated for both formats. When both `log4qt.properties` and `log4qt.json` exist, the `.properties` file takes priority, and the overall order is `.properties` over `.json` over `.xml`. The file is placed next to the executable or in the working directory.

Both formats can also be applied programmatically, and the programmatic path has a file-watching variant that reloads the configuration when the file changes.

#include <log4qt/jsonconfigurator.h>

Log4Qt::JsonConfigurator::configure("path/to/config.json");
// or with file watching:
Log4Qt::JsonConfigurator::configureAndWatch("path/to/config.json");

The equivalent exists for XML through `log4qt/xmlconfigurator.h` with `Log4Qt::XmlConfigurator::configure` and `configureAndWatch`.

Building with CMake, with the database and telnet parts off by default

The build is CMake based and the documentation is explicit that an out-of-source build is required, which means you cannot configure and build in the source tree.

The sequence is the standard CMake out-of-source dance.

    <unpack/fetch to Log4Qt directory>
    mkdir Log4Qt-build
    cd Log4Qt-build
    cmake ../Log4Qt
    make/mingw32-make/msbuild Log4Qt.sln
    make/mingw32-make install

The line with slashes in it is the documentation's shorthand for three platform-specific commands: make on Linux, mingw32-make on Windows with MinGW, or msbuild with the generated solution file. Which one you use depends on your toolchain, and the last line installs the result.

The four CMake options are the part to plan around. `-DBUILD_SHARED_LIBS=OFF` builds a static log4qt library, and it is on by default, so you get a shared library unless you ask otherwise. `-DBUILD_WITH_DB_LOGGING=ON|OFF` controls database logging support and defaults to OFF, which is the sane default given it pulls in a database driver. `-DBUILD_WITH_TELNET_LOGGING=ON|OFF` controls the telnet appender and defaults to ON. And `-DBUILD_WITH_QML_LOGGING=ON|OFF` controls QML logger support, also defaulting to ON.

Two of those defaults deserve a second look. The database logging is off, so if you were planning to use the DatabaseAppender you need to enable it before the configure step, not discover it afterwards. And the telnet appender is on by default, which means a network-facing listener is compiled into your library unless you turn it off. For a library whose whole point is writing to places other people can read, that default is worth a deliberate decision rather than an inherited one.

The clone step is a single command.

    git clone https://github.com/MEONMedical/Log4Qt.git

The repository itself has the usual CMake and Qt project furniture: a `CMakeLists.txt` at the root, a `cmake/` directory, `include/` and `src/` for the library, `examples/` with a basic example and a property configurator example, `tests/`, and a `doc/` directory. There is also a `Configuration.md` at the top level, which is where the configuration reference lives, a `ChangeLog.md`, and a `.astylerc` for code formatting.

The 2.0 line raised the floor to Qt 6.5 and C++20

The requirements section is where the version decision gets made, and it is not a soft constraint.

The minimum Qt version required is Qt 6.5. The documentation then spells out the fallback options: for support of Qt versions down to 5.3, use branch 1.4 or the latest 1.4.x release, and for support of Qt versions down to 5.7, use branch 1.6 or the latest 1.5.x release. C++20 is required, with a minimum compiler version of MSVC 19.29, which is Visual Studio 2019 16.11, or GCC 10, or Clang 10.

There is a sharp note about a specific toolchain combination. Qt 6.5 needs Visual Studio 2022 on Windows with MSVC, and the documentation states that Qt 6.5.3, the last open source 6.5 patch, does not compile with the Visual Studio 2026 toolchain, because its headers use the `stdext` array iterators that MSVC removed.

That is a specific trap for a Windows team on a current Visual Studio: the pinned minimum Qt version and the newest compiler do not go together, so you either stay on an older Visual Studio or move to a newer open source Qt patch. Either way the constraint comes from Qt's headers, not from Log4Qt, but it lands on your build matrix.

The release history explains the shape of the current line. v1.5.1 dates from 2020-02-14, then v2.0.0 on 2026-08-04 and v2.0.1 on 2026-09-22, with the last push to the repository on 2026-09-22. So the 1.x line sat for years and the 2.0 line landed in 2026 with a patch release a month later. The topics list both qt5 and qt6, which is a legacy of the branch structure rather than a claim about the current release.

The licence is Apache License 2, Version 2.0, with the LICENSE file at the top of the tree. For a library intended for both open source and commercial Qt projects, that is the permissive grant with an explicit patent clause and no copyleft reaching into your application.

Editorial conclusion

Log4Qt suits a C++ team building a Qt application that wants a familiar Log4j configuration model and a set of appenders, from rolling files to a SQL table, without writing that plumbing in house. It does not suit a project that is still on Qt 5, because the current line requires Qt 6.5 and C++20, and it does not suit a team that wants the library's own logging model rather than Log4j's, since the inheritance of the Log4j behaviour is the design rather than an accident. Verify first that your Qt version is new enough for the branch you take, that the build options you need are enabled before the compile rather than after, and that the configuration format you pick is the one the file priority rules actually resolve to when more than one file is present.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. MEONMedical/Log4Qt on GitHub
4. README
5. Releases