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
