cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <>
Subject Re: SitemapSource calls Pipeline twice, Logging issue in Avalon
Date Sat, 28 Jun 2003 12:12:01 GMT
Hello Volker!

vsbisc> My proposal is, remove the source.getURI from the logging statement or
vsbisc> change the getURI() implementation to not init the Source again.
Is this indeed possible? I personally would prefer this.
If for some reason it is not possible we may want to
scratch our heads again :)

vsbisc> Now to the Avalon Logging issue.
vsbisc> Hm I am wondering why
vsbisc>       if ( this.getLogger().isDebugEnabled() )
vsbisc> was true, because I had no log-level configured as DEBUG.

vsbisc> After a long time of debugging :-( I found two things.

vsbisc> 1. org.apache.avalon.framework.logger.LogKit2AvalonLoggerAdapter
vsbisc> In the method:

vsbisc> public static org.apache.log.Logger createLogger( final Logger logger )

Hmmm... looks like LogKit2AvalonLoggerAdapter does only
part of the job: the
calls are passed onto the wrapped avalon logger correctly, but
the .isDebugEnabled(), etc. are not passed at all. A good point.

I'm no guru here, but I would prefer a complete
LogKit2AvalonLoggerAdapter.createLogger() rewrite.

The best would be the reverse of LogKitLogger.
I only doubt how to name it.

I also doubt that it belongs to avalon framework.

But essentially we need a reverse of LogKitLogger.

vsbisc> I have add the following code after the creation of the logKitLogger

vsbisc> if (!logger.isDebugEnabled()) {
vsbisc>     if (!logger.isWarnEnabled()) {
vsbisc>         if (!logger.isErrorEnabled()) {
vsbisc>             logKitLogger.setPriority(Priority.FATAL_ERROR);
vsbisc>         } else {
vsbisc>             logKitLogger.setPriority(Priority.ERROR);
vsbisc>         }
vsbisc>     } else {
vsbisc>         logKitLogger.setPriority(Priority.WARN);
vsbisc>     }
vsbisc> }

Hmmm... another solution, it's inside the

method, isn't it? The idea is to deduct the log level of the
avalon logger we're wrapping and assign it to our LogKit logger..
A complete rewrite of this method looks better to me..

If there is a need to fix this class at all..

vsbisc> and vola, now the isDebugEnabled inside the SitemapSourceFactory return
vsbisc> false :-)
vsbisc> But then I wonder why is the Logger inside the SitemapSourceFactory is a
vsbisc> wrapped Logger, because SitemapSourceFactory impl. LogEnabled, so the
vsbisc> wrapping isn't needed. After an additional debugging session I found the
vsbisc> reason.

vsbisc> 2. org.apache.avalon.excalibur.component.DefaultComponentFactory
vsbisc> Method newInstance first checks if a Component implements "LogEnabled" and
vsbisc> after this it checks for "Loggable". The problem is, if a Component impl.
vsbisc> AbstractDualLogEnabled like ExcaliburComponentSelector the "setLogger"
vsbisc> method of AbstractDualLogEnabled impl. overwrites the prev. set Logger

Have I fixed this? :-)

  -        if( component instanceof Loggable )
  +        else if( component instanceof Loggable )

- Anton

View raw message