Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Ok, that's a good point. Now log4j always claims to be
the fastest
logging system, so I guess this isn't an issue anymore.
Well, they claimed it at that time also. Log4J has some very good
marketing ;-)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
snip/
IMO, this makes a big difference when debug is disabled,
especially with deep hierarchies as we have in Cocoon (need
to take some of my copious free time to setup performance test cases).
I consider this as an important design flaw in
Carsten Ziegeler cziegeler at s-und-n.de writes:
So, my suggestion is to:
- deprecate the use of LogKit
-0.5
I have been a great fan of LogKit since I first started using it through Cocoon.
Its slim feature set attains the admirable goal of keeping things simple, yet
it's powerful enough for
Unico Hommes wrote:
Carsten Ziegeler cziegeler at s-und-n.de writes:
So, my suggestion is to:
- deprecate the use of LogKit
-0.5
I have been a great fan of LogKit since I first started using
it through Cocoon.
Its slim feature set attains the admirable goal of keeping
things
Carsten Ziegeler cziegeler at s-und-n.de writes:
Unico Hommes wrote:
Carsten Ziegeler cziegeler at s-und-n.de writes:
So, my suggestion is to:
- deprecate the use of LogKit
-0.5
snip to make gmane happy/
Yes, that's true. My initial post was a little bit unclear :)
Unico Hommes dijo:
Since my firsts steps in Cocoon I wondered why it use LogKit and not the
award winning log4j. I understand we need to support it because lot of
code was written using it, but maybe the solution is to create a block
for Logkit? That way people that want to use it, can include
Antonio Gallardo agallardo at agssa.net writes:
Unico Hommes dijo:
Since my firsts steps in Cocoon I wondered why it use LogKit and not the
award winning log4j.
Without a doubt log4j is popular. But popularity is mostly only marginally based
on merit. It proves good marketing, wide
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
It is not deprecated.
Cheers, Stephen.
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know
what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
What's new in 2.0? I don't see any
Vadim Gritsenko wrote:
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know
what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
What's new in 2.0? I
Vadim Gritsenko wrote:
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know
what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
What's new in 2.0? I
Ok, this is all true - but considering performance it's imho neglectable
even if you consider that heavy xml parsing and stylesheet transformations
happen at the same time.
Maybe ;-)
I'll try to come up with real numbers soon!
Sylvain
Sylvain,
Although there is some overhead in the
Ceki Gülcü dijo:
At 02:43 PM 5/28/2004, Unico Hommes wrote:
Without a doubt log4j is popular. But popularity is mostly only
marginally
based
on merit. It proves good marketing, wide adoption and a large community.
But it
doesn't prove a it to be the best in terms of code quality, ease of use,
At 02:43 PM 5/28/2004, you wrote:
Antonio Gallardo agallardo at agssa.net writes:
Without a doubt log4j is popular. But popularity is mostly only marginally
based
on merit. It proves good marketing, wide adoption and a large community.
But it
doesn't prove a it to be the best in terms of code
On May 27, 2004, at 9:05 AM, Carsten Ziegeler wrote:
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
current logkit.xml for LogKit).
+1
As long as Cocoon is based on a non-static logging
Carsten Ziegeler dijo:
Many have suggested this in the past and as Ugo mentioned it
yesterday, I think it's time to check our logging strategy.
Currently we use LogKit as our base logging system. Unfortunately
we are using third party components that either use Log4J or
commons-logging. So
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
current logkit.xml for LogKit).
Is this change transparent to the end-user? I mean all I need to do ATM
to print logging statements is
Jorg Heymans wrote:
Is this change transparent to the end-user? I mean all I need
to do ATM to print logging statements is getLogger().debug()
or worste case implement Loggable.
Will this change then transparently hand you a log4j logger
or do I need to declare one of those pesky
Marco Rolappe wrote:
why depend explicitly on log4j instead of using
commons-logging? AFAIK when log4j is available
commons-logging automatically uses it before falling back to
JDK logger etc.
Currently - as we are using Avalon for our components - we use
an avalon logger which is not
Carsten Ziegeler wrote:
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
current logkit.xml for LogKit).
WDYT?
My only suggestion is to have a way of differentiating the logkit.xml
for LogKit
Carsten Ziegeler wrote:
Marco Rolappe wrote:
why depend explicitly on log4j instead of using
commons-logging? AFAIK when log4j is available
commons-logging automatically uses it before falling back to
JDK logger etc.
Currently - as we are using Avalon for our components - we use
an avalon
Carsten Ziegeler dijo:
and what do you mean by configuring log4j from within cocoon?
isn't it easy enough to put the log4j configuration file to
/WEB-INF/classes?
Of course this is a posiblity, but I don't like the idea of deploying the
configuration file in /WEB-INF/classes. INstead we can
Berin Loritsch dijo:
Carsten Ziegeler wrote:
So, my suggestion is to:
- deprecate the use of LogKit
- switch to log4j as default
- make it possible to configure log4j from within Cocoon (like the
current logkit.xml for LogKit).
WDYT?
My only suggestion is to have a way of
Carsten Ziegeler wrote:
Many have suggested this in the past and as Ugo mentioned it
yesterday, I think it's time to check our logging strategy.
Currently we use LogKit as our base logging system. Unfortunately
we are using third party components that either use Log4J or
commons-logging. So in the
Sylvain Wallez wrote:
Honestly, I don't see the need for such a change now that the
logger type can be chosen in web.xml.
This is a big concern for users, they simply want to use log4j.
Also, long ago, I compared the code of LogKit and Log4J and
found constructs in Log4J that made it
Carsten Ziegeler [EMAIL PROTECTED] writes:
Many have suggested this in the past and as Ugo mentioned it
yesterday, I think it's time to check our logging strategy.
Currently we use LogKit as our base logging system.
Unfortunately we are using third party components that either
use
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Honestly, I don't see the need for such a change now that the logger type can be chosen in web.xml.
This is a big concern for users, they simply want to use log4j.
Ok. So our experiences differ on that point.
Also, long ago, I compared the
Marco Rolappe wrote:
the only problem I have with directly using log4j is being
tied to it. if the code starts to use log4j specific features
you'll be no more (easily) able to move to another logger
implementation. and the issues with commons-logging
(classpath, etc.) will probably
Sylvain Wallez wrote:
Ok, that's a good point. Now log4j always claims to be the fastest
logging system, so I guess this isn't an issue anymore.
Well, they claimed it at that time also. Log4J has some very
good marketing ;-)
:) Marketing is everything!
Ok, I just checked the
Carsten Ziegeler dijo:
Sylvain Wallez wrote:
Ok, that's a good point. Now log4j always claims to be the fastest
logging system, so I guess this isn't an issue anymore.
Well, they claimed it at that time also. Log4J has some very
good marketing ;-)
:) Marketing is everything!
Ok, I
Marco Rolappe wrote:
okay, that clears everything up. nun sind alle klarheiten
beseitigt ;-)
:)
There is only a volunteer missing...
Carsten
Carsten Ziegeler wrote:
Many have suggested this in the past and as Ugo mentioned it
yesterday, I think it's time to check our logging strategy.
Currently we use LogKit as our base logging system. Unfortunately
we are using third party components that either use Log4J or
commons-logging. So in the
At 07:06 PM 5/27/2004, Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Many have suggested this in the past and as Ugo mentioned it
yesterday, I think it's time to check our logging strategy.
Currently we use LogKit as our base logging system. Unfortunately
we are using third party components
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Ok, that's a good point. Now log4j always claims to be the fastest
logging system, so I guess this isn't an issue anymore.
Well, they claimed it at that time also. Log4J has some very good
marketing ;-)
:) Marketing is everything!
Ok, I just checked
I'm on a family visit to Alaska and don't have a lot of time for email, so
I don't know if I'll get to read all the replies to this until I get back.
I added the code to allow any logger to be used (in addition to the
default and log4j) because we use our own custom logger. I really don't
care
Stefano Mazzocchi wrote:
WDYT?
The reason why logkit was developped was because log4j made extensive
use of static methods and that doesn't work very well with servlet
environments.
Ceki, anything to report on that front?
NOTE: Cocoon is getting fed up with avalon and its community
36 matches
Mail list logo
