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
