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
.debug()
.error()
etc.
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
LogKit2AvalonLoggerAdapter.createLogger()
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
