Logging crossing contexts
We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files. For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files. Any ideas out there for me to try?
Hi Robert, What happens when you revert to the previous versions of logback? Which versions are we talking about? -- Ceki http://tinyurl.com/proLogback On 13.08.2012 18:09, Robert Voliva wrote:
We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files.
For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files.
Any ideas out there for me to try?
What's weird is we haven't changed our version of logback or slf4j in quite some time. We're using logback 0.9.28 and slf4j 1.6.1 On Mon, Aug 13, 2012 at 11:27 AM, ceki <ceki@qos.ch> wrote:
Hi Robert,
What happens when you revert to the previous versions of logback? Which versions are we talking about? -- Ceki http://tinyurl.com/proLogback
On 13.08.2012 18:09, Robert Voliva wrote:
We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files.
For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files.
Any ideas out there for me to try?
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
On 13.08.2012 18:31, Robert Voliva wrote:
What's weird is we haven't changed our version of logback or slf4j in quite some time. We're using logback 0.9.28 and slf4j 1.6.1
OK but what happens when you revert to the previous version, in this case, 0.9.28? Cheers, -- Ceki http://tinyurl.com/proLogback
Have you upgraded any other components, like Mule itself? If yes, then Mule might be accidentally be polluting your classpath with another implementation of a component you use so the two contexts suddenly can see one another. You may want to do some investigations on what jars are available on your context classpath. A simple snippet searching for all MANIFEST.MF resources and then ask where it is located should allow you to get a list. /Thorbjørn From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Robert Voliva Sent: 13. august 2012 18:09 To: logback-user@qos.ch Subject: [logback-user] Logging crossing contexts We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files. For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files. Any ideas out there for me to try?
If my memory serves me correctly, the context selection code has not changed significantly since 0.9.28. How do you perform context selection? Is it JNDI based? Again, what happens when you revert to logback 0.9.28? -- Ceki http://tinyurl.com/proLogback On 14.08.2012 11:56, Thorbjørn Ravn Andersen wrote:
Have you upgraded any other components, like Mule itself?
If yes, then Mule might be accidentally be polluting your classpath with another implementation of a component you use so the two contexts suddenly can “see” one another.
You may want to do some investigations on what jars are available on your context classpath. A simple snippet searching for all MANIFEST.MF resources and then ask where it is located should allow you to get a list.
/Thorbjørn
*From:*logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] *On Behalf Of *Robert Voliva *Sent:* 13. august 2012 18:09 *To:* logback-user@qos.ch *Subject:* [logback-user] Logging crossing contexts
We run multiple apps in the same instance of Mule (ESB product), all in the same JVM. We use a context selector to setup each app with its own logging context at startup. This has worked fine for quite some time, we haven't upgraded/changed any slf4j or logback dependencies, and it suddenly stopped working. What's happening now is that we're getting parts of our logging ending up in other context's log files.
For example, we'll get a WARN message in the appropriate log file, but then a stack trace for that app will get logged to a different context's log file. It ends up in the same log file every time we restart, so it seems to be repeatable. Even if we remove all but two apps from the JVM, we can show that even with just those two apps they log to each other's log files.
Any ideas out there for me to try?
participants (3)
-
ceki -
Robert Voliva -
Thorbjørn Ravn Andersen