commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <jo...@j-hohwiller.de>
Subject Re: [logging] SLF4J?
Date Wed, 23 Aug 2006 21:33:50 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Boris,

> Your arguments against some bad design in some JDK libraries may be OK
> or not,
I maybe was a little harsh ;)

> but I do not see the point
> against JUL. I think there are still good arguments to use JUL:
> - I18N support with default JDK mechanisms (there may be better, OK, but
> the JCP decided to use this ones).
I care a lot about I18N. But I personally think that i18n has nothing lost
in loggers. Do you want to get bug-reports with japanese log-files?
The log-file is NOT for the end user. It might be ignorant: but which developer
can not understand english? How do we communicate on mailing lists?
The application itself should be able to support i18n for user feedback: in
exceptions, GUI, etc.
> - Good (not excellent) possibilities to extend/override/exchange the
> backend.
May be your oppinion but not mine.
> - No further dependencies than JDK1.4 or above
That is the major point
> - Interface of the logger-class has some good helper methods
I see no Interface. There is an overloaded Java-Class. Helpers should not be
part of the usage Interface but be add-on classes.
> - Supported by the major wrappers JCL causing no dependency problems if
> an API requires JCL
I am not sure if I get you wrong here. But we are talking about the API you are
using. You can of course use JCL together with JUL and everything is fine if
you get all the features you need. But if someone is using JUL directly it does
not help anyone if it can be adapted by JCL or whatever.
BTW have you tried to hot-configure the JUL system at runtime? Works fine with
log4j, though.
> - Supported by the currently niche player SLF4J causing no dependency
> problems if an API requires SLF4J
same as above.
> - Major issues solved in third party APIs (i.E., but not the only one,
> x4juli)

Okay we need to make sure what we are talking about. Maybe I got it wrong when I
catched up the discussion.

But there are two things to distinguis:
1) The API you are programming agains when you are writing code that wants to log.

2) The logging toolkit implementation

For me the important thing is 1). And JUL is NOT an acceptable API to me. But
JCL is.

For 2) you can use log4j or JUL or whatever you like.

I often have to integrate components from different open-source projects and
different vendors. This could be so easy if there was just one logging API (e.g.
JCL). Then I can choose for my complete application what logging toolkit I want
to use. Another one might choose a different one for the same application.
But the truth is different. One component uses JCL via LogFactory, one JUL, one
log4j, one logkit, one avalon, one DNA, one plexus, one metro, etc.
You end up with tons of logging jars and a situation that makes it impossible to
have a homogenous logging system for the application.
- From this point of view I can not see the point for slf4j!!!
Why can't log4j directly implement the JCL Log interface. I guess that the JCL
team would allow log4j team to include their Log interface in the log4j JAR
file. But Java classpaths somehow tend to be a political issue.

Regards
  Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE7Mm+mPuec2Dcv/8RAuCdAJ9ivXKYCOjxiXQM7GfPDFicC1dQrgCgl1de
44YN4Zeqd7h6rtKdcn9x6e8=
=xStS
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message