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 abstrac
At 02:43 PM 5/28/2004, you wrote:
Antonio Gallardo 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 quality, ease
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, e
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,
or the
most appropr
> >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 ove
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 d
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 d
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 changelogs
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.
Antonio Gallardo 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 adoption and a
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
Carsten Ziegeler s-und-n.de> writes:
>
> Unico Hommes wrote:
> >
> > Carsten Ziegeler s-und-n.de> writes:
> >
> > > So, my suggestion is to:
> > > - deprecate the use of LogKit
> >
> > -0.5
> >
> >
> Yes, that's true. My initial post was a little bit unclear :)
> The basic idea is to us
Unico Hommes wrote:
>
> Carsten Ziegeler 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 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 most of Co
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
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 Log4J, whic
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
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
instabiliti
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 wh
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 checke
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 that
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
Marco Rolappe wrote:
>
> okay, that clears everything up. nun sind alle klarheiten
> beseitigt ;-)
>
:)
There is only a volunteer missing...
Carsten
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 ;-)
>>
> :) "Marketi
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
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 probab
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 co
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
>
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 ma
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
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
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 c
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 log
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 and
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
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
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 getLogger(
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.
37 matches
Mail list logo