The point here is that the current logging implementation provides a simple way to associate codes with each user-facing log message and exception. This is helpful to those who may want to monitor logs for certain codes (e.g. for alerting purposes), filter some codes out, etc. In this way the logging is part of a contract with the users much like an API is a contract with developers. The codes stay consistent across versions but the content of the message may change (e.g. to provide more information, correct spelling errors, typos, etc.). This kind of facade also opens the door for fairly simple internationalization.
The goals here as I see them: - Maintain the aforementioned functionality. - Ditch the dependence on JBoss Log Manager and JBoss Logging. Having a simple implementation of our own is an easy way to do this. If we decide to go this route then (and only then) we will need to decide on the underlying logging facade and implementation. Justin On Tue, May 3, 2022 at 3:17 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Using SL4J makes sense to me as that is what almost everyone else uses so > it's pretty standard and easy to swap implementations > > On Mon, May 2, 2022 at 1:26 PM Justin Bertram <jbert...@apache.org> wrote: > > > I think this looks great, Clebert. The code is straightforward, and I > like > > the idea of reducing our dependencies. > > > > This is a +1 from me. > > > > > > Justin > > > > On Fri, Apr 29, 2022 at 3:43 PM Clebert Suconic < > clebert.suco...@gmail.com > > > > > wrote: > > > > > For a while, I thought it would be nice to remove jboss-logging from > > > artemis and use a generic logger. (SLF4J, Log4j, commons.. whatever.. > > > it's all orthogonal and transparent to this discussion, we can decide > > > that at a later point). > > > > > > > > > One of the issues we had while making the move would be the generated > > > error codes out of the Log Processor. > > > > > > > > > So, I put together a prototype here that would generate code based on > > > an interface and that could use whatever logger we choose. I will try > > > to never remove the branch for future reference: > > > > > > > > > > > > > > > https://github.com/clebertsuconic/activemq-artemis/tree/prototype-log-processor > > > > > > > > > > > > the Log processor would read the annotations and generate the code: > > > > > > > > > > > > https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/main/java/org/apache/activemq/artemis/logprocessor/processor/LogProcessor.java > > > > > > > > > > > > > > > A testcase here would show how such processing would work: > > > > > > > > > > > > https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/test/java/org/apache/activemq/i18n/test/SimpleBundleTest.java > > > > > > > > > I have added some code on the artemis-server, trying to simulate what > > > we would do in "real life": > > > > > > > > > > > > > > > https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerNewLogger.java > > > > > > > > > > > > This test here is making a call to the NewLogger, just to show how > > > processing would work. Everything would work just like it would now: > > > > > > > > > > > > https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/test/java/org/apache/activemq/artemis/core/TestSample.java > > > > > > > > > > > > > > > I would appreciate some feedback if this is a good way forward or > not... > > > > > > (please let's not diverge on what logging framework we are choosing > > > now... that's a separate discussion). > > > > > > > > > > > > > > > > > > -- > > > Clebert Suconic > > > > > > > > >
