Jacob Kjome skrev den 07-12-2008 06:04:
On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote:
I believe that the positive in decoupling the logging implementation
from the application will vastly overshadow any inconvinience in this
regard. Most if not all of the work has been done in the slf4j project.
Right. "Most if not all the work has been done". What is left? SLF4J has
succeeded in its aim. Congratulations! And I'm not being facetious here. So,
what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders
work well with it?
I believe that Curt Arnold may be somewhat right in that this is a
matter of Apache endorsement. This is purely guesswork.
I still think that log4j should have a "Best practices" list, where the
"use slf4j framework" should be on the list for backend independence, to
inform the users as early as possible.
Also, it seems to me that there is a clear advantage to the SLF4J project in
maintaining control of its own development. If there's some fundamental fix
that
needs to be done to all binders it can be done and released quickly; entirely
under the control of one project. Why move part of this control out to external
projects? What is the advantage of it? Wouldn't that necessitate Log4j to
coordinate its release cycles with SLF4J to a certain extent? Such a burden
seems
totally unnecessary as they can and have lived happily apart up to now.
You have a very valid point here. slf4j has not quite settled down yet
- IMO - regarding features and releases so it would make perfect sense
to keep log4j and slf4j distinct and disentangled.
I'm not sure about this whole "JUL has won the API war" thing? I guess I'd have
to hear more from Curt about why he believes this? I've never even considered
using JUL, but maybe that's just me?
j.u.l has a few advantages over log4j, one of them being it works
without a configuration file :)
However, the question of why Log4j has not provided adapters for JUL in the
1.2.xx
codebase is probably because it's somewhat of a dead end, development-wise. It
is
in maintenance mode. It generally works well, but there are fundamental issues
(threading) that can't be fixed without breaking compatibility. So, changes are
limited to those that preserve compatibility. The upside is that existing users
who have written custom extensions can upgrade and pick up fixes without having
to
worry about breakage. The downside is that the motivation to innovate remains
in
hibernation until someone gets cracking on Log4j 2.0. I, for one, seem to have
less and less time for this as the years go by; sad but true.
Other projects have created extra packages containing such auxillary
classes to avoid breaking things in the core package.
The reason must be another :)
Are you *ABSOLUTELY* certain you want to bring in politics in this
technical issue? In my opinion it will only mudden the waters!
I don't necessarily condone it, but I understand where it comes from. And
unless
you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably
won't
understand. All I can say is that there's a bit of Dejavu going on here
I did not follow the experience a few years back, so I don't understand
much. I do understand, however, that apparently this controversy caused
a project to fork, so it must have been bad.
"I propose that log4j implement the SLF4J API directly. This can be done in the
next version of log4j, say 1.3 or 2.0."
New versions which break stuff have a tendency to gain less adoption
from users.
Right now it is a bit vague talking about the next version of log4j, as
not much is happening which could warrant a new release. It appears
to me that most of the logging development taking place at the moment
happens in logback.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
