[
https://issues.jboss.org/browse/WFCORE-1512?page=com.atlassian.jira.plugi...
]
James Perkins commented on WFCORE-1512:
---------------------------------------
The {{DelegatingBasicLogger}} is part of the
[
jboss-logging|https://github.com/jboss-logging/jboss-logging] which is just a logging
facade. The {{LogContext}} is from the
[
jboss-logmanager|https://github.com/jboss-logging/jboss-logmanager] project which is an
extension of the JUL log manager. The generated logger interfaces don't have any
knowledge of the log manager.
The main issue is we're using static loggers. The loggers are created on a log context
once since the modules are only loaded once.
DelegatingBasicLogger could delegate to a Logger provider
---------------------------------------------------------
Key: WFCORE-1512
URL:
https://issues.jboss.org/browse/WFCORE-1512
Project: WildFly Core
Issue Type: Feature Request
Components: Logging
Reporter: Jean-Francois Denise
Assignee: James Perkins
Today the DelegatingBasicLogger subclass generated from @MessageLogger annotation is
bound to a Logger at construction time. It could be of interest (e.g: I ran by accident on
WFCORE-1187) to have the logger to be resolved dynamically.
I didn't evaluate the impact on the logging project/tools/performances of a solution
like the following but it captures the idea of a logger provider.
public class DelegatingBasicLogger {
public interface LoggerProvider
{ public Logger getLogger(); }
DelegatingBasicLogger(Logger logger) {
{ this(()->{return logger;})}
DelegatingBasicLogger(LoggerProvider provider)
{ this.provider = provider; }
....
}
A subclass could use LogContext to retrieve the right Logger.
class MyLogger extends DelegatingBasicLogger {
MyLogger(String category)
{ super(()->LogContext.getLogContext().getLogger()); }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)