Hi Ceki, Can you please explain your change of heart first? I'll take a guess as to your skepticism...
1. Very little built in support, making repository selectors generally a custom solution, which inhibits widespread use. This can be easily addressed. 2. The use of static loggers as well as logger abstractions such as commons-logging and SLF4J (unless you use an implementation that directly extends SLF4J, such as Logback) break respository selectors anyway. 3. Even implementations that purport to support respository selectors fail to truly support them in practice as evidenced by the fact that Logback - having been in full release for a good while - is just now being fixed to properly support them. 4. A common deployment model these days is one app per/server. In this case, separating logging between applications is unnecessary because there is only one application. That said, there's plenty of evidence, based on a quick search of the Log4j-user/dev mailing lists, that repository selectors are useful. In some cases, they are used to separate logging by some runtime attribute, such as IP address or thread, not just per/application (classloader or JNDI context). As such, choosing not to support the concept would disenfranchise a small, but nonetheless important, user base. Jake On 12/26/2008 7:05 AM, Ceki Gulcu wrote: > > Hello, > > I am in the process of fixing bugs related to context selectors in logback. > Context selectors are the equivalent of repository selectors in log4j. > However, > while few years back I thought that context selectors, aka repository > selectors, > were the wave of the future, I am increasingly skeptical about their > usefulness. > > If you are using context/repository selectors, could you please explain > why? > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
