As long as we can get those security issues released, I am fine. Personally I am fine with helping with the editor, if it stays as web app (I can do react and such). If it's JavaFX - I am lost. I have hard time helping with Swing in Chainsaw.
Since you mentioned its importance, we should work on a release very soon. It is really hard to justify the presence of those security issues, even when I understood from Matt that users need to chose their versions themselves. Still, I am not perfectly clear of what you will do with it and what the "additional audit apis" actually are. I have a feeling though. On Tue, Oct 10, 2023, at 22:53, Ralph Goers wrote: > 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 >>
