Re: [RT] Logging in Cocoon
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 abstraction, I'm happy. -pete
Re: [RT] Logging in Cocoon
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 of use, or the most appropriate solution for any given system. Good marketing? Hmm, log4j was never marketed. Sure, we have a web-site but we don't market log4j at all, and never have. What is this good marketing we've supposedly been doing? I'm interested. I apologize if this is way out off topic, but so is the myth of the log4j marketing steam-roller. -- Unico -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: [RT] Logging in Cocoon
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, >>or the >>most appropriate solution for any given system. > > Good marketing? Hmm, log4j was never marketed. Sure, we have a > web-site but we don't market log4j at all, and never have. What is > this good marketing we've supposedly been doing? I'm interested... > > I apologize if this is way out off topic, but I had to react to this > myth of the log4j marketing steam-roller. log4j was on the right place at the right time. Before log4j was nothing. After the log4j success, on each corner you find a clone. ;) Best Regards, Antonio Gallardo
Re: [RT] Logging in Cocoon
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 appropriate solution for any given system. Good marketing? Hmm, log4j was never marketed. Sure, we have a web-site but we don't market log4j at all, and never have. What is this good marketing we've supposedly been doing? I'm interested... I apologize if this is way out off topic, but I had to react to this myth of the log4j marketing steam-roller. -- Unico -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: [RT] Logging in Cocoon
> >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 way log4j does its lookup, you should discover that the overhead is in the nano-second range. Thus, for many applications the difference should be so small as to be unmeasurable. However, there are situations where the overhead makes a difference. In particular, when the logging is done at the "OS" or container level. We are aware of the problem. It will be addressed in future versions of log4j. In any case, I would be quite interested in the numbers you come up with. -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: [RT] Logging in Cocoon
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 don't see any changelogs at http://avalon.apache.org/logkit/ ... Nothing new in terms of features. The changes the prompted the the bump to 2.0.0 were related to removal of the AvalonFormatter class that tied the LogKit implementation to Avalon Framework (and the exposure of an operation to pass a specific formatter instance to LogKit LogTarget). End result - LogKit is now independent of Framework. Other changes to LogKit include some minor bug fixes and some small implementation improvements. Cheers, Stephen.
Re: [RT] Logging in Cocoon
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 don't see any changelogs at http://avalon.apache.org/logkit/ ... Mostly (from what I recall) cleaning out all the deprecated stuff (hense the 2.0 designation because it is not 100% backwards compatible with users who have not migrated off of the deprecated classes). The removal of the deprecated stuff should not in any way affect Cocoon. -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rich Cook
Re: [RT] Logging in Cocoon
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 at http://avalon.apache.org/logkit/ ... Vadim
Re: [RT] Logging in Cocoon
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.
Re: [RT] Logging in Cocoon
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 large community. But it doesn't prove a it to be the best in terms of code quality, ease of use, or the most appropriate solution for any given system. > I understand we need to support it because lot of > code was written using it, Actually there is very little code in Cocoon that depends on LogKit directly. When you use an Avalon Logger in your code this is not part of LogKit. Currently the default implementation *is* a LogKitLogger but you can also setup your system to use Log4jLogger, JDK14Logger, etc. > but maybe the solution is to create a block > for Logkit? It is important to distinguish between aspects of a system and its components. Logging clearly is an aspect as opposed to SPI level services like blocks. Although making Logkit support optional is possible, its not typically accomplished by making it into a block. -- Unico
Re: [RT] Logging in Cocoon
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 it. WDYT? Best Regard, Antonio Gallardo > > -- > Unico >
Re: [RT] Logging in Cocoon
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 use log4j as default and provide perhaps > a little bit more support for configuration of log4j - whatever > that require. Of course you still will be able to use logkit > if you want (so "deprecating" was a wrong term, sorry). > I am very happy to hear that :-) Thanks for clarifying. Having better support for log4j is definately a pro. And I am interested to see once more people start using it more how it compares to Logkit in Cocoon. > For the status of logkit, well, currently it's called "legacy" at > Avalon (please correct me, if I'm telling something wrong here). > As far as I remember, the idea is to not continue the development > of Logkit anymore. I see, and I understand the decision since there is now a logging TLP and logging should not be Avalon's concern anyway. Perhaps there is a place for Logkit at logging.apache.org. > But I think this is not a problem as Logkit > is working well and is "finished". There is no real need for > further development. Exactly my point. I don't remember ever having any problems with it. If people want a feature not supported by LogKit they can use Log4j. -- Unico
RE: [RT] Logging in Cocoon
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 simple, yet it's powerful enough for most of Cocoon's > usage scenarios. I think it is more intuitive to configure > than is Log4j. It's very well designed and it's specifically > designed with the kind of IoC log enabling in mind that we > will continue to use in the future. > > I understand the Avalon community argument and it is good to > have alternative logging solutions in Cocoon but I feel bad > about throwing out something I consider to be the best fit > logging package for Cocoon ATM. 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?). > > It is true that Log4j configuration is familiar to most > people and LogKit's just isn't. But that argument just > applies to new users of Cocoon. The ones that have been using > Cocoon are familiar with LogKit and may not be with Log4j. > Not that it is very difficult to learn to configure either of > them anyway ;-) > Yes, that's true. My initial post was a little bit unclear :) The basic idea is to use log4j as default and provide perhaps a little bit more support for configuration of log4j - whatever that require. Of course you still will be able to use logkit if you want (so "deprecating" was a wrong term, sorry). For the status of logkit, well, currently it's called "legacy" at Avalon (please correct me, if I'm telling something wrong here). As far as I remember, the idea is to not continue the development of Logkit anymore. But I think this is not a problem as Logkit is working well and is "finished". There is no real need for further development. Carsten
Re: [RT] Logging in Cocoon
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 Cocoon's usage scenarios. I think it is more intuitive to configure than is Log4j. It's very well designed and it's specifically designed with the kind of IoC log enabling in mind that we will continue to use in the future. I understand the Avalon community argument and it is good to have alternative logging solutions in Cocoon but I feel bad about throwing out something I consider to be the best fit logging package for Cocoon ATM. 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?). It is true that Log4j configuration is familiar to most people and LogKit's just isn't. But that argument just applies to new users of Cocoon. The ones that have been using Cocoon are familiar with LogKit and may not be with Log4j. Not that it is very difficult to learn to configure either of them anyway ;-) -- Unico
Re: [RT] Logging in Cocoon
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, which
would require a good amount of work to be fixed.
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 Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Logging in Cocoon
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 ;-)
> >>
> > :) "Marketing is everything!"
> >
> > Ok, I just checked the code. It seems that logkit is doing
> one check
> > (testing ints) for "isDebugEnabled()" while log4j is doing two. Now
> > this shouldn't really affect the performance I think.
>
>
> Look further in the code: there's actually mch more code
> behind it.
>
> public boolean isDebugEnabled() {
> if (repository.isDisabled(Level.DEBUG_INT)) {
> return false;
> }
> return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
> }
>
> Yep, two tests. reposorit.isDisabled() is an interface call
> (slower than a class call) which leads to a simple test (see
> Hierarchy). Now let's dig deeper:
>
> public Level getEffectiveLevel() {
> for (Category c = this; c != null; c = c.parent) {
> if (c.level != null) {
> return c.level;
> }
> }
> }
>
> This crawls up the category tree up to finding one that has a
> level explicitely set! And for each call!!
>
> This reveals what is IMO an important design flaw in Log4J:
> logger priorities are checked a bazillion more times than
> they are changed.
>
> LogKit, on the other hand, takes into account the fact that
> logger priorities are checked a bazillion more times than
> they are changed.
> Therefore, it propagates priority changes on child loggers,
> meaning the crawl isn't needed and code required to check the
> priority is really
> minimal:
>
> public final boolean isDebugEnabled() {
> return m_priority.isLowerOrEqual( Priority.DEBUG ); }
>
> 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, which
> would require a good amount of work to be fixed.
>
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.
Carsten
Re: [RT] Logging in Cocoon
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 instabilities and we'd like to move away from it as much as possible. Stefano: Did that make you feel all warm and fluffy inside? Seriously - if you have a problem avalon or its community you really should post your opinions to that community and avoid little background comments where possible. Your probably aware that there is a proposal to separate off the Excalibur content from Avalon - and I'm confident you will in future be paying careful attention to you usage of terminology - referring to Avalon when Avalon is the subject, and referring to Excalibur when Excalibur is the subject. Cheers, Stephen.
Re: [RT] Logging in Cocoon
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 what logger Cocoon uses as long is it is done through an interface that I can provide my own implementation of. Ralph Carsten Ziegeler said: > 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 end you have to configure more than > one logging system. > > Log4j is the standard for logging - I think this is obvious. > So, the easiest and most obvious solution is to use Log4J in > Cocoon as well. > Since 2.1.5 you can simply switch to Log4J if you configure > the logger-class parameter in web.xml. There is only one > drawback: log4j has to be configured "elsewhere"; this is > not done by Cocoon. > > 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? > > Carsten > > Carsten Ziegeler > Open Source Group, S&N AG > http://www.osoco.net/weblogs/rael/ > >
Re: [RT] Logging in Cocoon
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 the code. It seems that logkit is doing one check
(testing ints) for "isDebugEnabled()" while log4j is doing two. Now
this shouldn't really affect the performance I think.
Look further in the code: there's actually mch more code behind it.
public boolean isDebugEnabled() {
if (repository.isDisabled(Level.DEBUG_INT)) {
return false;
}
return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
}
Yep, two tests. reposorit.isDisabled() is an interface call (slower than
a class call) which leads to a simple test (see Hierarchy). Now let's
dig deeper:
public Level getEffectiveLevel() {
for (Category c = this; c != null; c = c.parent) {
if (c.level != null) {
return c.level;
}
}
}
This crawls up the category tree up to finding one that has a level
explicitely set! And for each call!!
This reveals what is IMO an important design flaw in Log4J: logger
priorities are checked a bazillion more times than they are changed.
LogKit, on the other hand, takes into account the fact that logger
priorities are checked a bazillion more times than they are changed.
Therefore, it propagates priority changes on child loggers, meaning the
crawl isn't needed and code required to check the priority is really
minimal:
public final boolean isDebugEnabled() {
return m_priority.isLowerOrEqual( Priority.DEBUG );
}
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, which would
require a good amount of work to be fixed.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Logging in Cocoon
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 either use Log4J or commons-logging. So in the end you have to configure more than one logging system. Log4j is the standard for logging - I think this is obvious. So, the easiest and most obvious solution is to use Log4J in Cocoon as well. Since 2.1.5 you can simply switch to Log4J if you configure the logger-class parameter in web.xml. There is only one drawback: log4j has to be configured "elsewhere"; this is not done by Cocoon. 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? 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. The static factory methods are syntactic sugar, or syntactic vinegar depending on your pov. If you control have control over your applications, you can use separate logger repositories if you wish to do so. If you use the JNDIContextSelector, log4j can even automatically manage the repositories for you. This is known as the logging separation problem. It is discussed here: https://www.qos.ch/logging/sc.html There is also an example of how to achieve separation here: http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/tiny-webapp/ I hope the above is relevant and makes sense. Ceki, anything to report on that front? Since you asked, log4j will soon be using itself for its own logging. Thus, log4j will restrict itself to the logging context in effect. So multiple applications will be able to share the same log4j.jar file, but have completely separate logging output where even log4j's own logging will be restricted to the application's logging context. The self-logging property is *vaguely* similar to XML being a self-describing language. In short we are pushing the LoggerRepository idea to its limits, even from within log4j itself. NOTE: Cocoon is getting fed up with avalon and its community instabilities and we'd like to move away from it as much as possible. In Avalon's defense I can say that it is far from trivial to ensure stability over the years. -- Stefano. -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: [RT] Logging in Cocoon
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 end you have to configure more than one logging system. Log4j is the standard for logging - I think this is obvious. So, the easiest and most obvious solution is to use Log4J in Cocoon as well. Since 2.1.5 you can simply switch to Log4J if you configure the logger-class parameter in web.xml. There is only one drawback: log4j has to be configured "elsewhere"; this is not done by Cocoon. 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? 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 instabilities and we'd like to move away from it as much as possible. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: [RT] Logging in Cocoon
Marco Rolappe wrote: > > okay, that clears everything up. nun sind alle klarheiten > beseitigt ;-) > :) There is only a volunteer missing... Carsten
RE: [RT] Logging in Cocoon
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 just checked the code. It seems that logkit is doing one > check (testing ints) for "isDebugEnabled()" while log4j is > doing two. Now this shouldn't really affect the performance I think. Hmmm Every milisec count! :-D Best Regards, Antonio Gallardo
RE: [RT] Logging in Cocoon
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 code. It seems that logkit is doing one check (testing ints) for "isDebugEnabled()" while log4j is doing two. Now this shouldn't really affect the performance I think. Carsten
RE: [RT] Logging in Cocoon
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 also be true for log4j. > Ah, ok, I see. Now, I wasn't very clear what I meant. Of course, I would like to have the used logging system still configurable like it is today. Today we ship Cocoon with LogKit preconfigured. What I meant is to change this to Log4j. As this is only the logging subsystem used by Avalon logging, no code of Cocoon has to be changed and we will not use log4j directly from our code. So we should be able to switch at any time. > > > > > 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? > > > > > Yepp, but we have to provide this configuration and perhaps > we have to > > think about possible configuration conflicts. For example > what happens > > if a third party project comes with a log4j conf as well. I think > > log4j handles this automatically but I'm not sure. > > maybe that's the core issue: providing the ability to > configure it; which logging implementation, the > implementation's config, generic logger definitions ala logkit.xconf. > Yepp. Carsten
Re: [RT] Logging in Cocoon
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 code of LogKit and Log4J and
found constructs in Log4J that made it intrinsically much
more slower than LogKit just to check is a log level is
enabled. It would be good to do a performance comparison with
the latest versions, as we have so many
getLogger().isDebugEnabled() around...
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 ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Logging in Cocoon
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 Log4J or commons-logging. So in the end you have to > configure more than one logging system. > > Log4j is the standard for logging - I think this is obvious. > So, the easiest and most obvious solution is to use Log4J in > Cocoon as well. Since 2.1.5 you can simply switch to Log4J if > you configure the logger-class parameter in web.xml. There is only one > drawback: log4j has to be configured "elsewhere"; this is > not done by Cocoon. > > 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? Yes please! Our developers end up configuring log4j for our Cocoon components simply because that's what they are familiar with and they never even think to try and figure out how to use LogKit...
RE: [RT] Logging in Cocoon
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 intrinsically much > more slower than LogKit just to check is a log level is > enabled. It would be good to do a performance comparison with > the latest versions, as we have so many > getLogger().isDebugEnabled() around... > 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. Carsten
Re: [RT] Logging in Cocoon
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 end you have to configure more than
one logging system.
Log4j is the standard for logging - I think this is obvious.
So, the easiest and most obvious solution is to use Log4J in
Cocoon as well.
Since 2.1.5 you can simply switch to Log4J if you configure
the logger-class parameter in web.xml. There is only one
drawback: log4j has to be configured "elsewhere"; this is
not done by Cocoon.
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?
Honestly, I don't see the need for such a change now that the logger
type can be chosen in web.xml.
Also, long ago, I compared the code of LogKit and Log4J and found
constructs in Log4J that made it intrinsically much more slower than
LogKit just to check is a log level is enabled. It would be good to do a
performance comparison with the latest versions, as we have so many
getLogger().isDebugEnabled() around...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Logging in Cocoon
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 differentiating the logkit.xml > for LogKit and the config file for Log4J. Either log4j.xml or > logging.log4j would be great. The thing is that Log4J comes with code > to parse and configure itself from an XML file whereas LogKit has that > as an add-on library. Good! I have a question too: What happen when we currently have more than one jars that implement his own log4j configuration? Will it work? Best Regards, Antonio Gallardo
RE: [RT] Logging in Cocoon
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 bundle it inside the cocoon-[VERSION].jar > Yepp, but we have to provide this configuration and perhaps we > have to think about possible configuration conflicts. For example > what happens if a third party project comes with a log4j > conf as well. I think log4j handles this automatically but I'm > not sure. Is here someone already subscribed on log4j list that could ask about that? Best Regards, Antonio Gallardo
Re: [RT] Logging in Cocoon
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 logger which is not directly logging but uses a logging subsystem. This subsystem can be logkit, log4j etc. I think commons-logging is possible as well. I honestly don't know if it's better to use commons-logging or directly use log4j. If you were to ask the original author of Log4J, the answer is simple: directly use Log4J. When I described to him how Avalon does the abstraction, he said he liked the sound of it better than the commons logging solution. What's wrong with commons logging? Nothing if you have a standalone application. However, it uses classpath discovery to determine if you have LogKit, Log4J, JDK 1.4 logging, and where the logging configuration file is. There have been many complaints of inconsistant configuration of the log files because of the uncertainty of the servlet classpath. If the implementers of your servlet engine inadvertently put a differing implementation than you want to use, there is a good chance you will be logging to your servlet container's targets instead of Cocoon's. Also if you have several instances of Cocoon under one "webapp" in your ServletContainer you may get some mixed results. I don't have all the links right now, but suffice it to say that Commons Logging uses black magic to set everything up at startup.
Re: [RT] Logging in Cocoon
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 the config file for Log4J. Either log4j.xml or logging.log4j would be great. The thing is that Log4J comes with code to parse and configure itself from an XML file whereas LogKit has that as an add-on library.
RE: [RT] Logging in Cocoon
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 directly logging but uses a logging subsystem. This subsystem can be logkit, log4j etc. I think commons-logging is possible as well. I honestly don't know if it's better to use commons-logging or directly use log4j. > 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? > Yepp, but we have to provide this configuration and perhaps we have to think about possible configuration conflicts. For example what happens if a third party project comes with a log4j conf as well. I think log4j handles this automatically but I'm not sure. Carsten
RE: [RT] Logging in Cocoon
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 private static > final Logger logger = Logger.getLogger(myclass.class) in each class? > No, no - of course this is completly transparent. We will not loose the IoC for loggers. So getLogger() returns you a Log4J logger - you don't have to change a single line in your code. Carsten
Re: [RT] Logging in Cocoon
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().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 private static final Logger logger = Logger.getLogger(myclass.class) in each class? Or did i miss your point entirely? Jorg
Re: [RT] Logging in Cocoon
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 in the end you have to configure more than > one logging system. > > Log4j is the standard for logging - I think this is obvious. > So, the easiest and most obvious solution is to use Log4J in > Cocoon as well. > Since 2.1.5 you can simply switch to Log4J if you configure > the logger-class parameter in web.xml. There is only one > drawback: log4j has to be configured "elsewhere"; this is > not done by Cocoon. > > 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? A big +1!! Best Regards, Antonio Gallardo
