Yes, I can update the dependencies and do a release. The primary issue with the project as it stands is the Catalog Editor UI. It is really stupid. It uses Spring Boot for the UI but it is meant to run locally. It was suggested I switch the UI to JavaFX but I have never had the chance.
FWWI - Log4j-Audit is the entire reason I created Log4j2. It cannot work with SLF4J/Logback. Ralph > On Oct 10, 2023, at 1:48 PM, Matt Sicker <m...@musigma.org> wrote: > > 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 >
