Log4j Audit has multiple components: * Audit API for extending log4j-api with some additional audit logging APIs * Tool for managing your audit event schemata and such (the web app thing) * Tool for generating structured log classes from the event schemata
Thus, in typical use, you can (and should) specify what version of log4j-core you’re using for your application. As for maintenance, the web UI could use an overhaul (though it would likely involve a rewrite into something more popular like React), but the overall library is fairly compact. I do have an outstanding Jira issue for Log4j to work on a more fluent API for structured logging, and that sort of feature can be informed or inspired by log4j-audit. As for the log4j-server question, I’d expect that if we adopt Flume into the PMC, then Flume would supersede the server examples since we’d have something far more mature and production-ready for such a use case. > On Oct 10, 2023, at 1:33 PM, Christian Grobmeier <grobme...@apache.org> wrote: > > Hello, > > We have been talking about log4j-audit (same thread as with log4j-server). > > I have checked today after seeing Piotr's message, and even after reading the > readme, I am still trying to figure out the purpose of this product. That > aside, I am concerned the last change was four years ago. -audit is depending > to Log4j 2.10, which is affected by log4shell. > > I checked on the releases, and I see only RCs here: > https://github.com/apache/logging-log4j-audit/tags > But two releases here: > https://logging.apache.org/log4j-audit/latest/download.html > > What message are we sending? > > As I understand it we are currently promoting software that contains > log4shell without any word of warning or any development plan on the horizon. > > Do we have any development cycles left to fix at least the security issues, > with the Flume project probably merging into this project? > > I am not asking for the "will power", but the "real power": if it is not > realistic to maintain this project, we should add warning labels, consider > EOL, and/or actively search for contributors. > > I am willing to support a bit, but only if I understand the use of -audit :) > > Kind regards, > Christian
