Hello,
this thread started at the user's list, but Ceki asked to answer on the
delevopers list for points regarding the implementation:
Ceki Gülcü wrote:
> A quick look at org.x4juli.X4JuliLogger and
> org.slf4j.impl.X4JuliLoggerFactory indicates that you have done a very
> good job. It is not ex
Comments inline.
At 10:26 PM 12/20/2005, Boris Unckel wrote:
[snip]
I think one of the most important design decisions (espescially in open
source) is freedom of choice within a custom (propietary) implementation.
A wrapper should (as slf4j does) be an interface so people can implement it
as t
Good Morning,
> To address this problem, you could split x4juli to x4juli.jar and
> slf4j-x4juli.jar (with the former depending on the latter). In this
> setting, slf4j-x4juli.jar would contain slf4j classes (o.s.Logger,
> o.s.ILoggerFactory, etc.) plus o.s.impl.StaticLoggerBinderbound to
> o.
At 10:35 AM 12/23/2005, Boris Unckel wrote:
Good Morning,
> To address this problem, you could split x4juli to x4juli.jar and
> slf4j-x4juli.jar (with the former depending on the latter). In this
> setting, slf4j-x4juli.jar would contain slf4j classes (o.s.Logger,
> o.s.ILoggerFactory, etc.) plu
Hello,
Ceki Gülcü wrote:
>> There may be another solution: The only difference betwen the default
>> JDK14LoggerFactory and X4JuliLoggerFactory is that X4JuliLoggerFactory
>> has a
>> compile-time dependendy to x4juli and detects wheter to use native
>> interface
>> or the normal wrapper class app
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 th
