You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <oz...@apache.org> on 2003/12/03 17:52:38 UTC
Added JDK1.4 logger
I just created a jdk14 folder in the proposals section to contain jdk14
specific classes. Initially it contains a Slide logger implementation
for the JDK1.4 built in logging. It is not included in the build for
now, but only for evalutation.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Added JDK1.4 logger
Posted by Christopher Lenz <cm...@gmx.de>.
Hi Oliver,
as Erik already pointed out, Commons-Logging can be completely
configured by the user using system properties. In addition, the
application using Commons-Logging can choose to use a push model
(passing the Log to "components" using a setLog() method) instead of
the pull model ("components" get their own log by calling
LogFactory.getLog()), and provide their own means for selecting the log
implementation. For Slide this means that the log implementation
*could* still be selected via Domain.xml, even though components
wouldn't be forced to use the supplied logger.
All that said, I think a migration to Commons-Logging would be a good
thing, because it provides a very lightweight and stable API (simpler
than the Slide abstraction, even, in a positive way) with
implementations for all common logging frameworks, so Slide would not
need to duplicate that code. Use of Commons-Logging has become quite
common for projects inside and outside of Apache, so developers usually
already know how to perform logging with it.
Note that I'm not volunteering to do the migration, I was throwing in
the idea/concern when I saw that you added the implementation for
JDK1.4 logging to Slide, thus duplicating effort that has already gone
into Commons-Logging. Not that it's a lot of effort, really. But in the
long term the Commons-Logging code is probably getting a lot more
attention, exposure and testing.
--
Christopher Lenz
/=/ cmlenz at gmx.de
Am 04.12.2003 um 10:38 schrieb Oliver Zeigermann:
> Christopher Lenz wrote:
>
>> Oliver,
>> this might have been discussed before... anyway, any reason not to
>> migrate to using Commons-Logging, which already includes adapters for
>> Log4J, JDK1.4 and the Avalon Logkit?
>
> Well, it has been discussed before and we even had a vote that said:
>
>> Logging API will be augmented by a method allowing for both message
>> and
>> throwable in one call. A general redesign of logging is deferred to
>> later releases.
>
> Anyway, for later releases, here is my comment: I have tried
> commons-logging and it seems to have a very strong bias towards log4j.
> It seemed to me if there is log4j anywhere in the classpath it will
> use this, even though the user might want to use other logging
> implementations.
>
> Every more severe is the need to touch (at least that's what I
> understand) every spot in the code that does logging. That's pretty
> much of an impact. So, the discussion could be "is it worth it"?
>
> Oliver
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Added JDK1.4 logger
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Stefano Mazzocchi wrote:
>
> On 4 Dec 2003, at 01:38, Oliver Zeigermann wrote:
>
>> Christopher Lenz wrote:
>>
>>> Oliver,
>>> this might have been discussed before... anyway, any reason not to
>>> migrate to using Commons-Logging, which already includes adapters for
>>> Log4J, JDK1.4 and the Avalon Logkit?
>>
>>
>> Well, it has been discussed before and we even had a vote that said:
>>
>>> Logging API will be augmented by a method allowing for both message and
>>> throwable in one call. A general redesign of logging is deferred to
>>> later releases.
>>
>>
>> Anyway, for later releases, here is my comment: I have tried
>> commons-logging and it seems to have a very strong bias towards log4j.
>> It seemed to me if there is log4j anywhere in the classpath it will
>> use this, even though the user might want to use other logging
>> implementations.
>>
>> Every more severe is the need to touch (at least that's what I
>> understand) every spot in the code that does logging. That's pretty
>> much of an impact. So, the discussion could be "is it worth it"?
>
>
> I agree, there are more important things to do. But, personally, I
> wouldn't stop anybody from doing it, just I wouldn't do it myself.
Same with me :)
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Added JDK1.4 logger
Posted by Stefano Mazzocchi <st...@apache.org>.
On 4 Dec 2003, at 01:38, Oliver Zeigermann wrote:
> Christopher Lenz wrote:
>
>> Oliver,
>> this might have been discussed before... anyway, any reason not to
>> migrate to using Commons-Logging, which already includes adapters for
>> Log4J, JDK1.4 and the Avalon Logkit?
>
> Well, it has been discussed before and we even had a vote that said:
>
>> Logging API will be augmented by a method allowing for both message
>> and
>> throwable in one call. A general redesign of logging is deferred to
>> later releases.
>
> Anyway, for later releases, here is my comment: I have tried
> commons-logging and it seems to have a very strong bias towards log4j.
> It seemed to me if there is log4j anywhere in the classpath it will
> use this, even though the user might want to use other logging
> implementations.
>
> Every more severe is the need to touch (at least that's what I
> understand) every spot in the code that does logging. That's pretty
> much of an impact. So, the discussion could be "is it worth it"?
I agree, there are more important things to do. But, personally, I
wouldn't stop anybody from doing it, just I wouldn't do it myself.
--
Stefano.
Re: Added JDK1.4 logger
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Thursday, December 4, 2003, at 04:38 AM, Oliver Zeigermann wrote:
> Anyway, for later releases, here is my comment: I have tried
> commons-logging and it seems to have a very strong bias towards log4j.
> It seemed to me if there is log4j anywhere in the classpath it will
> use this, even though the user might want to use other logging
> implementations.
While log4j is something it looks for if not configured otherwise, it
is quite simple to configure to use a different implementation even if
log4j is on the classpath. A system property can be set to control
which implementation is used:
http://jakarta.apache.org/commons/logging/userguide.html#Users
This document also provides all the gory details:
http://jakarta.apache.org/commons/logging/api/org/apache/commons/
logging/package-summary.html
While I have found logging to be a big pain in all my recent
applications, at least by using Commons Logging everyone can configure
it how they want using whatever lower level logging framework they
want. Slide developers would no longer have to deal with it at a
configuration level, just point to the above docs and say "it's your
problem" :)
> Every more severe is the need to touch (at least that's what I
> understand) every spot in the code that does logging. That's pretty
> much of an impact. So, the discussion could be "is it worth it"?
Unifying logging is important though, and whether we like Commons
Logging or not, the fact is that its pervasive and not too bad. I use
it in my applications and I recently had to configure the output. We
don't have log4j in the classpath at all, so it was using JDK1.4
logging - and so all I had to do was set a system property (for JRun)
that pointed to my specific .properties file that controlled how I
wanted the output.
I'm +1 on Commons Logging in Slide 2 :)
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Added JDK1.4 logger
Posted by Oliver Zeigermann <ol...@zeigermann.de>.
Christopher Lenz wrote:
> Oliver,
>
> this might have been discussed before... anyway, any reason not to
> migrate to using Commons-Logging, which already includes adapters for
> Log4J, JDK1.4 and the Avalon Logkit?
Well, it has been discussed before and we even had a vote that said:
> Logging API will be augmented by a method allowing for both message and
> throwable in one call. A general redesign of logging is deferred to
> later releases.
Anyway, for later releases, here is my comment: I have tried
commons-logging and it seems to have a very strong bias towards log4j.
It seemed to me if there is log4j anywhere in the classpath it will use
this, even though the user might want to use other logging implementations.
Every more severe is the need to touch (at least that's what I
understand) every spot in the code that does logging. That's pretty much
of an impact. So, the discussion could be "is it worth it"?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: Added JDK1.4 logger
Posted by Christopher Lenz <cm...@gmx.de>.
Oliver,
this might have been discussed before... anyway, any reason not to
migrate to using Commons-Logging, which already includes adapters for
Log4J, JDK1.4 and the Avalon Logkit?
--
Christopher Lenz
/=/ cmlenz at gmx.de
Am 03.12.2003 um 17:52 schrieb Oliver Zeigermann:
> I just created a jdk14 folder in the proposals section to contain
> jdk14 specific classes. Initially it contains a Slide logger
> implementation for the JDK1.4 built in logging. It is not included in
> the build for now, but only for evalutation.
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org