Hello Ceki,
Switching log files can be accomplished by a new appender which can embed and manage appenders based on MDC values. This sounds like a vialable way, that somehow matches my current log4j based hack. Is this appender already available? I had a quick look at the 0.9.11 sources and didn't find any.
Additional detail would be nice. For example, how are you managing thread local values in the web-app and in ejbs? For web-apps I currently use a servlet filter, which sets a thread special thread local variable to the value of a special context param in the webapp. This matches the MDC approach using servlet filters.
For ejb's this proves a bit more difficult (at least EJB2, havent checke EJB3 so far) since there is no standardized support for custom EJB interceptors. Currently I am using aspectj to weave an aspect around the ejb implementation class - which sets the thread local. A third use case are workmanager and timer threads (Websphere 6.1), where the aspect aproach also works - here the context setting aspect is applied the work item implementation classes (basically a Runnable implementation). I'll answer separately on your other, most recent mail. Regards, Lars Ceki Gulcu schrieb:
Lars Ködderitzsch wrote:
Hello Ceki,
thanks for the heads up on this issue on the mailing list.
Starting off I'd like to mention that for me the most wanted feature is separation of logging from different contexts (e.g. war's, ejb) of of an enterprise application (ear), without needing to resort to classloader stunts, multiple repeated logging configurations etc.
That means that the contexts of an enterprise app should be able to use the same logging implementation (that is placed in the ear classloader) and the same logging configuration, but ultimately the log into different log files. This way it can be truely sorted out, which context logged which message.
To my knowledge such a thing is supported in neither logging implementations. Currently I am running this as a hack on log4j, based on a specialized appender which switches the underlying log file based on some thread local, which in turn is set by a special servlet filter in each web context.
If your're interested I can elaborate more on the problem, so you can get a better understanding what would actually be needed.