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. At the time trying logback I thought that context selectors could achieve that in a better, more standardized and less hacky way. Ultimately I failed at the time and haven't looked back yet at logback. So back to the question, yes, I would be very much interested in such a feature - be it contexts selectors or something else. If your're interested I can elaborate more on the problem, so you can get a better understanding what would actually be needed. Best regards, Lars Ceki Gulcu schrieb:
Hello all,
I am in the process of fixing bugs related to context selectors in logback. However, while sometime ago I thought that context selectors were the wave of the future, I am increasingly skeptical about their usefulness (of context selectors).
If you are using context selectors, could you please explain why?