If I understand you correctly, it seems the central issue isn't that logback has a lifecycle, it's that you cannot manage the lifecycle without a compile-time dependency on logback.
If it were possible to shut down an org.slf4j.LoggerFactory, would that be a satisfactory solution? In other words, suppose you could include a shutdown hook or a context listener that invoked a shutdown method on the logger factory:
org.slf4j.LoggerFactory.shutdown();
slf4j could perhaps support this by providing the means for the underlying provider (e.g. logback) to register itself with slf4j for lifecycle callbacks. Or perhaps slf4j could check to see if the provider implements a given slf4j lifecycle interface.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
If I understand you correctly, it seems the central issue isn't that logback has a lifecycle, it's that you cannot manage the lifecycle without a compile-time dependency on logback.
If it were possible to shut down an org.slf4j.LoggerFactory, would that be a satisfactory solution? In other words, suppose you could include a shutdown hook or a context listener that invoked a shutdown method on the logger factory:
slf4j could perhaps support this by providing the means for the underlying provider (e.g. logback) to register itself with slf4j for lifecycle callbacks. Or perhaps slf4j could check to see if the provider implements a given slf4j lifecycle interface.