At 10:17 PM 1/5/2006, Boris Unckel wrote:
I hope to release x4juli 0.7 soon. Can you estimate a timeframe when the next slf4j version will arrive? Can you give me a hint whether you accept the patch in Bugzilla #10 or not?
Although a benign refactorization, I tend to decline the patch for the sample reason that it does not have any practical effect. Unless I misunderstood something, it does not solve the x4juli+slf4j+log4j problem (you would still need to split x4juli into two parts).
Your refactorization puts additional onus on the JDK14LoggerFactory class. It would now have to be aware that other implementation of JDK14Logger such as X4JULI exist. Moreover, x4juli can achieve the same result by replacing JDK14LoggerFactory class with X4JULILoggerFactory, which you have already done.
Is the strategy to check the underlying log system something for the o.s.i.Log4jLoggerFactory to avoid wrapper classes when nlog4j is present?
No there is no strategy for nlog4j and log4j to co-exist *simultaneously*. In the same way as you would not want to have two distinct versions of any given library on the class path, the user has to choose between placing nlog4j.jar or log4j.jar on her class path, but not both.
Regards Boris
-- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ _______________________________________________ dev mailing list dev@slf4j.org http://slf4j.org/mailman/listinfo/dev
