Re: [Aperture-devel] Logging: instance loggers and SLF4J

[Herko t. H. <her...@ad...>]

> It is thin, but its not as easy to use as java logging.
> You have to read additional documentation, developers need more 
> training, and you have two problems and two points of failure when using 
> it, first SLF4J can fail and then the underlying framework can fail.

 From a coding point of view, I think SLF4J is actually easier to use 
than Java logging. Of course, if all you have ever used before is Java 
logging, then yes, this is an additional thing to learn, but it's really 
simple (it's called Simple Logging Framework 4 Java for a reason), not 
in the least because the concepts are pretty much the same across all 
frameworks.

As far as reliability goes: because SLF4J doesn't actually do the 
decision-making, formatting or actual logging, the chances of anything 
going seriously wrong within the SLF4J framework are very small. All it 
does is accept logging calls and forward them to the actual logging 
implementation.

> Then, you have to manage two additional configuration file formats - 
> SLF4J and the underlying logger framework.

Not true, because SLF4J is *only the interface* to program to. The 
actual framework implementation controls what type of configuration is 
needed, so you can keep using your existing Java Logging or log4j 
configuration without change.

> If people use alternate logging implementations as default logging for 
> their applications, then they can use some forwarding mechanism to catch 
> the java logger messages and forward them to the log-framework of their 
> choice.

All these forwarding mechanisms are exactly what SLF4J already provides. 
JUL, log4j, Apache Commons Logging are all supported out of the box.

> This guy suggests to only use non-standard loggers if you need their 
> features. I don't see that we need these features.
> http://java.sys-con.com/read/48541_2.htm

SLF4J isn't an alternative for Java Logging or Log4J in the way 
described in that article. As such it doesn't have "more" or "better" 
features. For example, SLF4J doesn't have handlers, formatters or 
whatever. All it does is provide the *library* programmer with an 
interface to program too. The actually logging is done by whatever 
logging implementation is selected for the end-user *application*.

> I see that using a non-standard logger + abstraction layer always cries 
> for having two additional jars in your code, two jars that are unneeded. 
> Again, all non-standard logger frameworks are pre-2002, we have 2007 now.

SLF4J was started in 2005 because it was obvious at that time that 
multiple logging implementations were available which would continue to 
be used for a long time to come. For example, log4j isn't going away 
anytime soon. It has a huge installed base and I imagine that most of 
those applications will continue to use log4j for new versions.

> Also, logging isn't that mysterious rocket science, and java.logging is 
> ok enough for most applications, why think about this stuff and waste 
> endless time to choose the "right" logging framework if SUN provides one 
> that works for 90% of all cases pretty well?

The problem is that we don't control "most applications". Most 
applications are written by others and they will select the logging 
implementation of their preference. Being able to use the Aperture 
libraries in any application, regardless of the logging implementation 
it uses seems like a big plus to me.

So if you want to keep using JUL in your applications based on Aperture, 
that's fine, no problem at all. If at Aduna we want to start using log4j 
for our web-based products because we don't want to rely on the servlet 
container to solve the LogManager problem for us, that's fine too. If 
<insert random Apache project here> wants to keep using Apache Commons 
Logging for their application, but still be able to integrate Aperture, 
that will work as well.

> If its just the nerdy discussion "which logging framework has better 
> features, mine is better than yours", I would definitly go for jul. JUL 
> was created as a copy/paste of all the other framworks that were out 
> there before 2002, it is a JSR, its the right descision.

It's not a discussion of better or more features, it's a discussion of 
forcing a logging *implementation* on users of the library because we 
selected a particular logging *API*. SLF4J allows you to select the 
logging implementation at *deployment* time just by dropping in the 
correct jar file.

Cheers,

Herko