Slf4j is a no brainer to me. Let’s do it.
On Tue, May 3, 2022 at 4:31 PM Justin Bertram <jbert...@apache.org> wrote: > 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 > > > > > > > > > > > > > > -- Clebert Suconic
