I have doubts about a layer of abstraction that depends only on SLF4J, and hence has no idea what the end user wants to do with logging, thinking it is in a position to know whether or not it is appropriate to shut down logging.
My use-case is the other way around. Its the following use case:
Me, the end user which operates a whole lot of different software components on different hosts
wants to log to a central location. I tried syslog, rsyncing logs, ... but wasn't satifisfied with that.
Therefore I configured all software components with a logback.xml to use a LogbackSocketAppender. Where the software didn't support I used various adapters (log4j-to-slf4j, juli-adapters etc.).
This solution worked well enough for me until now. However, if logback now requires special maintenance hooks in order to be able to use the SocketAppender, I will need a lot of parties to modify there software...
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
Robert Elliot wrote:
My use-case is the other way around. Its the following use case:
Me, the end user which operates a whole lot of different software components on different hosts
wants to log to a central location. I tried syslog, rsyncing logs, ... but wasn't satifisfied with that.
Therefore I configured all software components with a logback.xml to use a LogbackSocketAppender. Where the software didn't support I used various adapters (log4j-to-slf4j, juli-adapters etc.).
This solution worked well enough for me until now. However, if logback now requires special maintenance hooks in order to be able to use the SocketAppender, I will need a lot of parties to modify there software...