I will push a temporary branch into gitbox.apache.org/repos/asf/activemq-artemis.git named new-logging
This branch will be later removed and all the commits squashed accordingly before we push a change into main. This is just to make it easier for multiple people to work on the same branch while we are working on this. I don't mind much about the commit messages at this point as they are all going to be squashed... On Sat, May 7, 2022 at 12:24 AM Michael André Pearce <michael.andre.pea...@me.com.invalid> wrote: > > +1 for switching to slf4j > > My only one and main comment will be that it is essential that the out the > box configuration should result in the same log formats and codes as today, > as I know many rely on log format parsing and rules for alerting, so to be > non breaking change the log output should be identical. > > Sent from my iPad > > > On 4 May 2022, at 18:27, Arthur Naseef <a...@amlinv.com> wrote: > > > > +1 on SLF4J - that's what it does: eliminate the tight coupling of code > > generating log output from the logging implementation. > > > > For testing, I would just make the logger injectable, but configure a > > default. Here's a "Live Template" for intellij that does this (minus the > > getter and setter): > > > > private static final org.slf4j.Logger DEFAULT_LOGGER = > > org.slf4j.LoggerFactory.getLogger($CLASS$.class); > > > > > > private org.slf4j.Logger log = DEFAULT_LOGGER; > > > > > > Cheers! > > > > Art > > > > > >> On Wed, May 4, 2022 at 8:15 AM Matt Pavlovich <mattr...@gmail.com> wrote: > >> > >> Hey Clebert- > >> > >> We just did this as part of log4j2 conversion. Here is a sample test > >> class w/ in-line appender: > >> > >> > >> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java > >> < > >> https://github.com/apache/activemq/blob/ae30dce4e24ce5e0467d2a3219627cbefef1f0ae/activemq-unit-tests/src/test/java/org/apache/activemq/usage/StoreUsageLimitsTest.java > >>> > >> > >> Matt Pavlovich > >> > >>> On May 4, 2022, at 7:37 AM, Clebert Suconic <clebert.suco...@gmail.com> > >> wrote: > >>> > >>> A few questions I have: > >>> > >>> - One of things we do in the testsuite is to capture loggers with an > >>> interceptor and assert the loggers were called. How would we do such a > >>> thing? an appender? Can someone point me to a test in ActiveMQ5 doing > >>> that? > >>> > >>> - how would you configure Log4J? (assuming we are using log4j with SLF4j) > >>> > >>> - also we have separate loggers for Auditing... I think that will be > >>> just an entry on the log4j configuration. > >>> > >>> On Wed, May 4, 2022 at 8:16 AM Clebert Suconic > >>> <clebert.suco...@gmail.com> wrote: > >>>> > >>>> MDC seems nice, but I don't think it's relevant here.. we need the > >>>> Codes as part of the messages where they appear. Some users will > >>>> create alerts for them on their log frameworks. > >>>> > >>>> On Wed, May 4, 2022 at 1:16 AM Christoph Läubrich <m...@laeubi-soft.de> > >> wrote: > >>>>> > >>>>> SLF4J support the "Mapped Diagnostic Context" > >>>>> > >>>>> maybe this would be a good replacement here? you could even add more > >>>>> context infos then and people are free to format them as they like: > >>>>> > >>>>> https://logback.qos.ch/manual/mdc.html > >>>>> > >>>>> Am 03.05.22 um 22:30 schrieb Justin Bertram: > >>>>>> 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 > >>> > >>> > >>> > >>> -- > >>> Clebert Suconic > >> > >> -- Clebert Suconic
