[slf4j-dev] Static binding...
Ceki Gulcu
ceki at qos.ch
Fri Nov 27 16:01:44 CET 2009
Hi Joern,
The idea behind static binding was to employ the least sophisticated
java idiom available, so that anyone could read and understand the
code within minutes. This had the additional benefit of making it
easier to debug problems in the field as well.
StaticLoggerBinder.SINGLETON has been replaced with
StaticLoggerBinder.getSingleton() a few years ago. It's a minor change
from a design point of view. The design of SLF4J, as far the binding
stategy is concerned, has not really changed since the
beginning. We've added defensive code but that's about it.
Getting the logger through reflection would actually cleaner from a
packaging point of view. However, we wouldn't be as a dumb as we
possibly can. :-)
Joern Huxhorn wrote:
> Hi Ceki,
>
> I asked it here because the static binding of the actual logging
> implementation is a seemingly important SLF4J feature. My guess is that
> this was important when SLF4J was still using
> StaticLoggerBinder.SINGLETON and now it's only there for historical
> reasons.
>
> I'm interested in those subtle differences. I'm not aware of any.
>
> Also, I'm asking the question because I've gone completely insane.
>
> I started an slf4j-redesign at
> http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api/
>
> You were right, btw. My initial idea wouldn't have worked in case of
> Logger deserialization. But I avoided that problem, now.
>
> My plan is the following (as documented in NewLoggerWrappingOld):
> It is used if a binding does not implements org.slf4j.n natively, i.e.
> the class org.slf4j.n.impl.StaticLoggerBinder does not exist. In that
> case, a fallback ILoggerFactory implementation is used that returns an
> instance of this class containing the logger returned by
> org.slf4j.LoggerFactory.getLogger(..).
>
> I've not finished the implmenetation (LoggerFactory isn't done yet) but
> the n.Logger interface looks as planned and the implementation of
> AbstractLogger NewLoggerWrappingOld and OldLoggerWrappingNew are more or
> less done.
>
> The LoggerFactory implementation, as planned, would require me to get
> the singleton using
> ILoggerFactory factory=(ILoggerFactory)
> Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);
>
>
> That's why I'm asking...
>
> Regards,
> Joern.
>
> On 26.11.2009, at 17:55, Ceki Gülcü wrote:
>
>> Hi Joern,
>>
>> Well, it's more of a java question than slf4j. The difference is
>> between direct method call and a method call via reflection. The
>> latter is known to be a bit slower and is also harder to read. There
>> might also be subtle class loader differences.
>>
>> Joern Huxhorn wrote:
>>> I was wondering if there is a real substantial difference between
>>> a) ILoggerFactory
>>> factory=org.slf4j.impl.StaticLoggerBinder.getLoggerFactory();
>>> and
>>> b) ILoggerFactory factory=(ILoggerFactory)
>>> Class.forName("org.slf4j.impl.StaticLoggerBinder").getMethod("getLoggerFactory").invoke(null);
>>> I mean, are the classes resolved any different?
>>> Beside a compile-time error in case of a) if the class is missing, of
>>> course.
>>> Regards,
>>> Joern.
>>
>> --
>> Ceki
>> _______________________________________________
>> slf4j-dev mailing list
>> slf4j-dev at qos.ch
>> http://qos.ch/mailman/listinfo/slf4j-dev
>
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev
More information about the slf4j-dev
mailing list