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
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
