If the web container capture java.util.logging logs (like Glassfish) a reasonable solution would be to tell them to use slf4j, and to deploy with the slf4j-jdk14 bridge. Note that I’ve recently found that the slf4j-jdk14 1.6.4 has a serialization bug pending, which affects this for instance loggers. I am testing a fix at <https://github.com/ravn/slf4j/tree/master/slf4j-jdk14> https://github.com/ravn/slf4j/tree/master/slf4j-jdk14. Would this work for you? /Thorbjørn From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Michael McCarthy Sent: 9. februar 2012 19:31 To: logback-user@qos.ch Subject: [logback-user] Overriding the logback file in an application via a system property I'm an application developer currently working with our sysops team around logging. Their problem is that everyone who writes an app logs in entirely their own way, often to the filesystem with no consideration for a standardised logging format. I've been looking into logback and so far so good...my idea is that when a developer deploys to the container, the container overrides the logback.xml file via the system property with it's own one, that then logs via gelf to something like graylog. I've been trying this locally and I don't seem to get any messages being sent to graylog...my suspicion is that jboss finds the application's logback file then ignores the system property. Am I correct in assuming this is right, or should the system property override the logback that is in the jar? Out of interest, does this seem a valid solution for standardised logging? Thanks Michael