Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

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
 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  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  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 
> >> 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
> >>>  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 
> >> 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 
> >> wrote:
> >>>
>  I think this looks great, Clebert. The code is straightforward, and
> >> I
> >>> like
>  the idea of reducing our dependencies.
> 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Michael André Pearce]

+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  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  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 
>> 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
>>>  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 
>> 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 
>> 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 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Étienne Hossack]

Thanks for clarifying Justin, Clebert.

+1 to the approach Art is highlighting. 

One of the problems with the log4j migration we had in AMQ5 (and as Matt has 
linked) is that the test classes are coupled to the logging framework (log4j 
specifically). So if there was a need to switch to say, logback, it couldn't be 
done "at the drop of a hat".

What Art has written only depends on Slf4j and mockito which is a huge plus.

--
Étienne

On Wed, 4 May 2022, at 10:29 AM, Arthur Naseef wrote:
> In case the testing part is not entirely clear, after making the logger
> injectable, then use a Mock in the test; like this:
>
> Logger mockLogger = Mockito.mock(Logger.class);
> target.setLog(mockLogger);
>
> ...
>
> Mockito.verify(mockLogger).info("Started");
>
> Art
>
> On Wed, May 4, 2022 at 10:27 AM Arthur Naseef  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  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 
>>> 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
>>> >  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 
>>> 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 
>>> 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, 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Arthur Naseef]

In case the testing part is not entirely clear, after making the logger
injectable, then use a Mock in the test; like this:

Logger mockLogger = Mockito.mock(Logger.class);
target.setLog(mockLogger);

...

Mockito.verify(mockLogger).info("Started");

Art

On Wed, May 4, 2022 at 10:27 AM Arthur Naseef  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  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 
>> 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
>> >  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 
>> 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 
>> 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 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Arthur Naseef]

+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  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 
> 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
> >  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 
> 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 
> 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:
> >>>
> >>>
> >>>
> >>
> >
> 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Matt Pavlovich]

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
 


Matt Pavlovich

> On May 4, 2022, at 7:37 AM, Clebert Suconic  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
>  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  
>> 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  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":
>>> 
>>> 
>>> 
>>> 
>> 
> 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

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
 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  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  
> > >> 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
> > 

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

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  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  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

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Christoph Läubrich]

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  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

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

It’s just the least possible work as we currently already have annotation
in the mix.

We need to keep the IDs as some users parse them.

On Tue, May 3, 2022 at 2:22 PM Étienne Hossack  wrote:

> Jumping back to the specific approach...
>
> Out of curiousity, why add in annotation processing to the mix? Seems like
> a clever enough approach, but most projects I've worked with don't involve
> annotations/code generation in the logging mix (apart from e.g. Lombok +
> Slf4j annotations).
>
> Clebert, what do you see as the alternative to using annotations for this
> (what you considered before proposing this approach)?
>
> --
> Étienne
> he/him/his
>
> On Tue, 3 May 2022, at 10:15 AM, Timothy Bish wrote:
> > On 4/29/22 16:36, Clebert Suconic 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).
> >>
> >>
> >>
> >>
> >>
> > +1
> >
> > Agree with others that slf4j would be a good choice
> >
> > --
> > Tim Bish
>
-- 
Clebert Suconic

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Justin Bertram]

> Out of curiousity, why add in annotation processing to the mix?

To be clear, no annotation processing is being added, per se. The
annotation processing is already there and has been for years at this
point. The question is whether or not our own simple re-implementation is a
good way forward to maintain the essential functionality we already have
and also to slim our dependencies.


Justin

On Tue, May 3, 2022 at 3:59 PM Étienne Hossack  wrote:

> Jumping back to the specific approach...
>
> Out of curiousity, why add in annotation processing to the mix? Seems like
> a clever enough approach, but most projects I've worked with don't involve
> annotations/code generation in the logging mix (apart from e.g. Lombok +
> Slf4j annotations).
>
> Clebert, what do you see as the alternative to using annotations for this
> (what you considered before proposing this approach)?
>
> --
> Étienne
> he/him/his
>
> On Tue, 3 May 2022, at 10:15 AM, Timothy Bish wrote:
> > On 4/29/22 16:36, Clebert Suconic 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).
> >>
> >>
> >>
> >>
> >>
> > +1
> >
> > Agree with others that slf4j would be a good choice
> >
> > --
> > Tim Bish
>
>

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

Slf4j is a no brainer to me.  Let’s do it.


On Tue, May 3, 2022 at 4:31 PM Justin Bertram  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 
> 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

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[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  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
> > >
> > >
> >
>

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Étienne Hossack]

Jumping back to the specific approach...

Out of curiousity, why add in annotation processing to the mix? Seems like a 
clever enough approach, but most projects I've worked with don't involve 
annotations/code generation in the logging mix (apart from e.g. Lombok + Slf4j 
annotations).

Clebert, what do you see as the alternative to using annotations for this (what 
you considered before proposing this approach)?

--
Étienne
he/him/his

On Tue, 3 May 2022, at 10:15 AM, Timothy Bish wrote:
> On 4/29/22 16:36, Clebert Suconic 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).
>>
>>
>>
>>
>>
> +1
>
> Agree with others that slf4j would be a good choice
>
> -- 
> Tim Bish

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Timothy Bish]

On 4/29/22 16:36, Clebert Suconic 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).






+1

Agree with others that slf4j would be a good choice

--
Tim Bish

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Robbie Gemmell]

Sounds like a good idea to me too.

On Mon, 2 May 2022 at 18:26, Justin Bertram  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 
> 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
> >
> >

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Robbie Gemmell]

Yep, I made the same comment elsewhere earlier, using SLF4J delegating
to something else like Log4J2 makes the most sense to me.

On Tue, 3 May 2022 at 17:10, Christopher Shannon
 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  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  > >
> > 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
> > >
> > >
> >

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Christopher Shannon]

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  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  >
> 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
> >
> >
>

Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis

[Justin Bertram]

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 
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
>
>

[DISCUSS] Use a generic logger in ActiveMQ Artemis

[Clebert Suconic]

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