[logging] SLF4J?

[James Carman <ja...@carmanconsulting.com>]

So, have we missed the boat?

http://www.slf4j.org

Is SLF4J going to take over?  I do like the fact that it relies on the user
dropping the correct jar file in the classpath to choose the implementation
(sounds familiar).



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

Re: [logging] SLF4J?

[Joerg Hohwiller <jo...@j-hohwiller.de>]

-----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

Re: [logging] SLF4J?

[Boris Unckel <bo...@gmx.net>]

Hello Jörg,

Joerg Hohwiller wrote:
>> But in the end, JCL will continue to improve as will SLF4J I expect, and
>> people can choose as they wish - until j.u.logging knocks both libs into
>> the dustbin of history.
>>     
I do not think that JUL will knock out JCL or SLF4J[1]. JCL is much too 
spreaded. JUL itself (without
homegrown additions or Tomcat-JULI[2] or x4juli[3]) has too less 
features (especially the handlers and the configuration[4])
too compete successfully against log4j or its derivates nlog4j[5] or 
logback[6].
> just to let you know my oppinion:
>
> this will never ever happen.
> j.u.l is crap because it does NOT have something that one can call an API!
>   
Could you specify that with specific design errors? I know the 
argumentation of Ceki, who has written something
before JDK 1.4 JSRs were finalized and tried to put log4j in place. 
Please do not repeat them - what did _you_ mean?
> I do not know what they drink at sun's but the jdk is full of rotten design
> mistakes.
> Some highlights:
> * See Calendar.get(int). And a Month starts with 0, but day with 1.
>   
This has nothing to do with JUL.
> * Why does Iterator not extend Enumeration
>   
This has nothing to do with JUL.
> * See the complete collections and
>   OperationNotSupportedException - is that an API?
>   
This has nothing to do with JUL.
> I know its not always easy to design a great API and of course JDK is the most
> central part so there will always be someone complaining. At least the newer
> things get designed better.
>
> Serious applications will continue NOT to use j.u.l !!!
>   
Your arguments against some bad design in some JDK libraries may be OK 
or not, 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).
- Good (not excellent) possibilities to extend/override/exchange the 
backend.
- No further dependencies than JDK1.4 or above
- Interface of the logger-class has some good helper methods
- Supported by the major wrappers JCL causing no dependency problems if 
an API requires JCL
- Supported by the currently niche player SLF4J causing no dependency 
problems if an API requires SLF4J
- Major issues solved in third party APIs (i.E., but not the only one, 
x4juli)
> Please keep going with JCL - hey, ho :)
Yes, JCL is cool and the new 1.1 release makes life much easier, 
especially its new diagnostic functions and its improved
exception/error messages. Great job. Hopefully containers who 
use/distribute it, will turn to this version.
JCL, especially its logger interface and neutral LogFactory is still the 
number one choice for API developers.
Classloader problems are based on missing knowledge, odd/strange 
behaviour of containers and the need
for the absolute maximum flexibility demanded by the users and/or 
design/implementation goals of the developers.

The static binding approach of SLF4J could be achieved with one build 
script and one or two binding classes -
may be a good optional turn for "self-compilers".

Regards
Boris

[1] http://www.slf4j.org
[2] http://tomcat.apache.org/tomcat-5.5-doc/logging.html
[3] http://www.x4juli.org
[4] http://java.sun.com/j2se/1.5.0/docs/guide/logging/index.html
[5] http://www.slf4j.org/nlog4j/
[6] http://www.logback.com

Re: [logging] SLF4J?

[Joerg Hohwiller <jo...@j-hohwiller.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there,

> But in the end, JCL will continue to improve as will SLF4J I expect, and
> people can choose as they wish - until j.u.logging knocks both libs into
> the dustbin of history.
just to let you know my oppinion:

this will never ever happen.
j.u.l is crap because it does NOT have something that one can call an API!
I do not know what they drink at sun's but the jdk is full of rotten design
mistakes.
Some highlights:
* See Calendar.get(int). And a Month starts with 0, but day with 1.
* Why does Iterator not extend Enumeration
* See the complete collections and
  OperationNotSupportedException - is that an API?

I know its not always easy to design a great API and of course JDK is the most
central part so there will always be someone complaining. At least the newer
things get designed better.

Serious applications will continue NOT to use j.u.l !!!

Please keep going with JCL - hey, ho :)

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

iD8DBQFE5N3OmPuec2Dcv/8RAl9AAKCFd6dWhYdOvm00Aa0PipB+JeLitQCdGBMo
xMzusRvgkZhDuu+r0NMt9f4=
=TgBP
-----END PGP SIGNATURE-----

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

Re: [logging] SLF4J?

[Simon Kitching <sk...@apache.org>]

On Fri, 2006-03-10 at 00:17 -0500, Sandy McArthur wrote:
> On 3/9/06, James Carman <ja...@carmanconsulting.com> wrote:
> > So, have we missed the boat?
> >
> > http://www.slf4j.org
> >
> > Is SLF4J going to take over?  I do like the fact that it relies on the user
> > dropping the correct jar file in the classpath to choose the implementation
> > (sounds familiar).
> 
> I think 1.4 j.u.logging is going to take over eventually. As time
> passes people care less and less about older JVMs. The fact that j.u.l
> already available to the programmer without any extra effort and not
> an external dependency means a lot to people who don't prioritize
> their passions as: their god, their country, their logging api, and
> then their family. That said, inertia will keep clogging and log4j
> around for a good while.

There are good reasons to continue work on JCL regardless of the
existence of SLF4J, in particular the fact that there is a large volume
of code using the JCL API, but having problems with the current JCL
implementation.

What logging library people choose for their projects is then their
business as far as I am concerned. A "market share" is something
commercial operators need to worry about; all we need to concern
ourselves with is creating good code. JCL1.0.x has flaws but has
generally been a success. JCL1.1 is expected to fix a significant number
of those flaws. Ideas are being considered for a JCL2.x to fix the rest.

I also agree that j.u.logging will eventually be the standard API. It's
not a great design IMO but the fact that it's in the language core
counts for a lot. However that's likely to be at least 3 years in the
future even for container-like apps, and maybe 10 years for *all* uses
of java < 1.4 to disappear (esp. embedded systems).

For standalone applications, SLF4J is a fine solution. For use in
containers, I have some significant concerns about SLF4J. I may be wrong
but we'll soon see I guess (assuming SLF4J actually starts to get a
fraction of the use that JCL currently has). I believe that JCL 1.1 will
be pretty good for containers, and JCL2 even better.

But in the end, JCL will continue to improve as will SLF4J I expect, and
people can choose as they wish - until j.u.logging knocks both libs into
the dustbin of history.

Cheers,

Simon


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

Re: [logging] SLF4J?

[Sandy McArthur <sa...@apache.org>]

On 3/9/06, James Carman <ja...@carmanconsulting.com> wrote:
> So, have we missed the boat?
>
> http://www.slf4j.org
>
> Is SLF4J going to take over?  I do like the fact that it relies on the user
> dropping the correct jar file in the classpath to choose the implementation
> (sounds familiar).

I think 1.4 j.u.logging is going to take over eventually. As time
passes people care less and less about older JVMs. The fact that j.u.l
already available to the programmer without any extra effort and not
an external dependency means a lot to people who don't prioritize
their passions as: their god, their country, their logging api, and
then their family. That said, inertia will keep clogging and log4j
around for a good while.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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