I'm getting the "substitute logger" error message yet my appender still works
Hi, I've written a custom appender that extends AppenderBase<ILoggingEvent> and put it in a library. I have a webapp that uses the custom appender. When I deploy that webapp to Tomcat I get the SLF4J error message "The following loggers will not work because they were created during the default configuration phase of the underlying logging system." The loggers listed are my custom appender plus the Spring JDBC classes the appender depends on (my appender logs to a table). My appender, however, works just fine. I get entries in my table just as expected. Is this error message something to be concerned about or am I receiving it in error? Thanks, Paul
You get this error because your Appender, or one of its dependencies, uses SLF4J for logging and that creates a recursive configuration problem for SLF4J/Logback - you need access to the logging context before the current logging context has been fully constructed. SLF4J solves this by giving the Logger a minimal logging context that won't log. Interestingly, I encountered the same problem in my work on Log4j 2.0 and was able to solve it in a different manner so that the subordinate Logger will work properly after the LoggerContext is fully configured. The only concern here is if you really need logging to function within the components being set up during the construction of the Appender. Ralph On Mon, Oct 24, 2011 at 8:33 AM, Paul Gifford <pggifford@gmail.com> wrote:
Hi,
I've written a custom appender that extends AppenderBase<ILoggingEvent> and put it in a library. I have a webapp that uses the custom appender. When I deploy that webapp to Tomcat I get the SLF4J error message "The following loggers will not work because they were created during the default configuration phase of the underlying logging system." The loggers listed are my custom appender plus the Spring JDBC classes the appender depends on (my appender logs to a table).
My appender, however, works just fine. I get entries in my table just as expected.
Is this error message something to be concerned about or am I receiving it in error?
Thanks,
Paul
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Thanks Ralph - you nailed it. I have a logger set up in my appender, but I don't use it during my appender's construction. I'm going to remove that logger and see if I get the same error message. Paul On Mon, Oct 24, 2011 at 12:24 PM, ralph.goers @dslextreme.com < rgoers@apache.org> wrote:
You get this error because your Appender, or one of its dependencies, uses SLF4J for logging and that creates a recursive configuration problem for SLF4J/Logback - you need access to the logging context before the current logging context has been fully constructed. SLF4J solves this by giving the Logger a minimal logging context that won't log. Interestingly, I encountered the same problem in my work on Log4j 2.0 and was able to solve it in a different manner so that the subordinate Logger will work properly after the LoggerContext is fully configured.
The only concern here is if you really need logging to function within the components being set up during the construction of the Appender.
Ralph
On Mon, Oct 24, 2011 at 8:33 AM, Paul Gifford <pggifford@gmail.com>wrote:
Hi,
I've written a custom appender that extends AppenderBase<ILoggingEvent> and put it in a library. I have a webapp that uses the custom appender. When I deploy that webapp to Tomcat I get the SLF4J error message "The following loggers will not work because they were created during the default configuration phase of the underlying logging system." The loggers listed are my custom appender plus the Spring JDBC classes the appender depends on (my appender logs to a table).
My appender, however, works just fine. I get entries in my table just as expected.
Is this error message something to be concerned about or am I receiving it in error?
Thanks,
Paul
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
On 24/10/2011 5:33 PM, Paul Gifford wrote:
Hi, I've written a custom appender that extends AppenderBase<ILoggingEvent> and put it in a library. I have a webapp that uses the custom appender. When I deploy that webapp to Tomcat I get the SLF4J error message "The following loggers will not work because they were created during the default configuration phase of the underlying logging system." The loggers listed are my custom appender plus the Spring JDBC classes the appender depends on (my appender logs to a table). My appender, however, works just fine. I get entries in my table just as expected. Is this error message something to be concerned about or am I receiving it in error? Thanks, Paul
Hi Paul, Have you read http://slf4j.org/codes.html#substituteLogger ? -- Ceki http://twitter.com/#!/ceki
Ceki, I have, many times. That's why I was confused as to why my logger was working as I thought it would be set to the nop logger. Paul On Mon, Oct 24, 2011 at 12:28 PM, ceki <ceki@qos.ch> wrote:
On 24/10/2011 5:33 PM, Paul Gifford wrote:
Hi, I've written a custom appender that extends AppenderBase<ILoggingEvent> and put it in a library. I have a webapp that uses the custom appender. When I deploy that webapp to Tomcat I get the SLF4J error message "The following loggers will not work because they were created during the default configuration phase of the underlying logging system." The loggers listed are my custom appender plus the Spring JDBC classes the appender depends on (my appender logs to a table). My appender, however, works just fine. I get entries in my table just as expected. Is this error message something to be concerned about or am I receiving it in error? Thanks, Paul
Hi Paul,
Have you read http://slf4j.org/codes.html#**substituteLogger<http://slf4j.org/codes.html#substituteLogger> ?
-- Ceki http://twitter.com/#!/ceki
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Hi Paul, Logback components should use the status manager for their internal logging. The fact that your custom appender references a logger will not affect the way it works except that the log messages originating from within your appender or from one of its dependencies will be discarded. You have 3 options: 1) use the status manager for internal messages 2) retrieve loggers anew until a real logger instance is returned (and not an NOPLogger) 3) place your custom appender in another configuration file as explained in http://slf4j.org/codes.html#substituteLogger -- Ceki On 24/10/2011 6:36 PM, Paul Gifford wrote:
Ceki, I have, many times. That's why I was confused as to why my logger was working as I thought it would be set to the nop logger. Paul
Thanks Ceki, I'll update my code to use the status manager. Regards, Paul On Mon, Oct 24, 2011 at 3:05 PM, ceki <ceki@qos.ch> wrote:
Hi Paul,
Logback components should use the status manager for their internal logging.
The fact that your custom appender references a logger will not affect the way it works except that the log messages originating from within your appender or from one of its dependencies will be discarded.
You have 3 options:
1) use the status manager for internal messages 2) retrieve loggers anew until a real logger instance is returned (and not an NOPLogger) 3) place your custom appender in another configuration file as explained in http://slf4j.org/codes.html#**substituteLogger<http://slf4j.org/codes.html#substituteLogger> -- Ceki
On 24/10/2011 6:36 PM, Paul Gifford wrote:
Ceki, I have, many times. That's why I was confused as to why my logger was working as I thought it would be set to the nop logger. Paul
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
You also mentioned that in addition to the logger named after the class of you custom appender, loggers for the Spring JDBC classes your appender depended on also were initialized with NOPLoggers. If you are interested in the logs from Spring JDBC classes, then your best bet is a two step configuration. -- Ceki On 24/10/2011 10:17 PM, Paul Gifford wrote:
Thanks Ceki, I'll update my code to use the status manager. Regards, Paul On Mon, Oct 24, 2011 at 3:05 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
Oh, right, that's an important consideration...thanks for catching that! I have the two-step configuration working (thanks for the good example) but what's the best way to mirror the application's Spring logging setting? Is there a way to capture what the application settings are for Spring? The way I understand how the two-step configuration works is: 1. Application starts, some logging configured 2. Logging configured for classes that depend on loggers created in step 1. Does step 2 depend on the user of the library (i.e. other developers) creating a 2nd Logback configuration file or is it possible to either ship an appropriate configuration file or to configure logging for the classes in step 2 dynamically? Thanks, Paul On Mon, Oct 24, 2011 at 4:21 PM, ceki <ceki@qos.ch> wrote:
You also mentioned that in addition to the logger named after the class of you custom appender, loggers for the Spring JDBC classes your appender depended on also were initialized with NOPLoggers. If you are interested in the logs from Spring JDBC classes, then your best bet is a two step configuration. -- Ceki
On 24/10/2011 10:17 PM, Paul Gifford wrote:
Thanks Ceki, I'll update my code to use the status manager. Regards, Paul On Mon, Oct 24, 2011 at 3:05 PM, ceki <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Simply move the configuration of your custom appender to another secondary configuration file. Load this file in a second configuration step. That's it. You don't have to worry about loggers references by Spring classes. -- Ceki http://twitter.com/#!/ceki On 24/10/2011 10:45 PM, Paul Gifford wrote:
Oh, right, that's an important consideration...thanks for catching that!
I have the two-step configuration working (thanks for the good example) but what's the best way to mirror the application's Spring logging setting? Is there a way to capture what the application settings are for Spring? The way I understand how the two-step configuration works is: 1. Application starts, some logging configured 2. Logging configured for classes that depend on loggers created in step 1. Does step 2 depend on the user of the library (i.e. other developers) creating a 2nd Logback configuration file or is it possible to either ship an appropriate configuration file or to configure logging for the classes in step 2 dynamically? Thanks, Paul
Wow...that was easy...thanks! Paul On Mon, Oct 24, 2011 at 4:50 PM, ceki <ceki@qos.ch> wrote:
Simply move the configuration of your custom appender to another secondary configuration file. Load this file in a second configuration step. That's it. You don't have to worry about loggers references by Spring classes. -- Ceki http://twitter.com/#!/ceki
On 24/10/2011 10:45 PM, Paul Gifford wrote:
Oh, right, that's an important consideration...thanks for catching that!
I have the two-step configuration working (thanks for the good example)
but what's the best way to mirror the application's Spring logging setting? Is there a way to capture what the application settings are for Spring? The way I understand how the two-step configuration works is: 1. Application starts, some logging configured 2. Logging configured for classes that depend on loggers created in step 1. Does step 2 depend on the user of the library (i.e. other developers) creating a 2nd Logback configuration file or is it possible to either ship an appropriate configuration file or to configure logging for the classes in step 2 dynamically? Thanks, Paul
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
participants (3)
-
ceki -
Paul Gifford -
ralph.goers ＠dslextreme.com