Hello,
It is a bit clearer now. I think the discussion boils down to a question of splitting the work and responsibility. In the current set up, SLF4J is oblivious to the existence of X4JULI and I would like to keep it that way. With the changes you propose, given that slf4j-jdk14.jar would become dual purpose (JUL and X4JULI). Thus, I'd need to test that slf4j-jdk14.jar worked with JUL and X4JULI, additional responsibility which at present time I would like to avoid.
Conversely, you would prefer to be unburdened by the need to synchronize your code with SLF4J without needing to fetch source code from the SLF4J branch. I propose to review the difficulty of synchronization in a few months time after we have more hindsight on the matter. Would that be OK with you?
At 09:52 PM 1/9/2006, Boris Unckel wrote:
Hello, I quoted from two messages regarding the same point, sorry, but they belong together: > Given that you already have this code in X4JuliLoggerFactory class, there > is no benefit in replicating it in JDK14LoggerFactory. >From http://article.gmane.org/gmane.comp.java.slf4j.devel/437 > 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). There would remain some classes in x4juli: o.s.Logger o.s.i.MessageFormatter. I would not provide an slf4j-x4juli.jar because there is already one: the slf4j-jdk14.jar which detects the native implementation. This seems to me a solution for the x4juli+slf4j+log4j case. If the user wants to use JDK logging (and has x4juli in the backenend of the JDK logging) he gets the optimal solution (without any tricks, just by putting slf4j-jdk14.jar on the classpath and remove any other). If the user wants to use slf4j-log4j12.jar with logj4 (or any other), he puts in that jar. There would be no need for an slf4j-x4juli.jar, because the intention of the user is clearly expressed when using slf4j-jdk14.jar. By the design of JUL (not! by x4juli) you cannot choose between x4juli and JUL in the same JVM at runtime. No user will enable x4juli and wonder why his JDK logging goes through it. But he will wonder, if slf4j-log4j12.jar x4juli.jar is present and the slf4j calls go through x4juli. > 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. Yes, once per load of the class, and without any tricky detecting (Is there a problem with instanceof I am not aware of?) > Moreover, x4juli can achieve the same result by replacing > JDK14LoggerFactory class with X4JULILoggerFactory, which you have already > done. Yes, thats right. But I would have to split the jars and have additional work with keeping all other slf4j classes in sync with the slf4j source tree. That would not be needed if the patch has been applied. Once the interface of slf4j has a release status, changes will affect all using code and therefor less likely. Please review the patch again under two points: Which disadvantages are there for users who do not use x4juli and want to use (the patched) slf4j-jdk14.jar with JUL? How fast can a bugfix regarding the factory/any other feature of slf4j be passed to x4juli without a copy of the classes in the x4juli source tree? Regards Boris
-- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
