avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <atagu...@mail.cnt.ru>
Subject avalon-excalibur/logger refactoring
Date Wed, 11 Jun 2003 12:52:06 GMT
Hello, Gentlemen!

Have just completed putting into the cvs
my thoughts on *LoggerManager design.

Maybe I was in too much hurry to commit
this to cvs right away, but anyhow the
code is already there.

I would like you to have a look a give
you comments.

Please start at the
and proceed to

I hope that I have learned something from the designs
in other parts of the system and here is the result :-)


The motivation was that

* LogKitLoggerManager was getting crafty

* there were disagreements on whether for instance the root
  logger obtained from the LoggerManager
  (getDefaultLogger() and getLoggerForCategory(""))
  should be overrideable or not
I started thinking about factorization of this all
into a number of building blocks of which any desired
functionality could be built.

Looks like I have achieved this goal.

And given that LoggerManager is not expected
to be a performance bottleneck (mostly consulted at
startup) the little performance penalty that I have
probably introduced does not look critical.


BTW, the PrefixDecorator has got one more purpose.
I do not know whether it will be proper of not, but
here's what I had in mind when writing it:

if container A manager container B, like

    A - - > B

A could probably do

    new PrefixDecorator( m_loggerManager, 'b' )

and pass this new LoggerManager to B.

Thus all logging done by B would go to categories
other then used by A.


In fact it's just an idea, I do not if it's good or bad,
it needs discussion, but I'm only demonstrating why I
consider PrefixDecorator double-purpose.


So, I'm expecting your comments.


To add to this, the final aim was probably
to replace LogKitLoggerManager with something like:

LogKitLoggerManager extends LogKitDecorator
    LogKitLoggerManager( args )
        args = process( args ); //meta-code :-)
        LoggerManager enclosed =
            Facade.createLogKitConfigurable( args );

        super.setLoggerManager( enclosed ); // this method currently
                                     // does not exist, so we'll add
                                     // it

to short-circuit the old classname to the new implementation.

If this is all approved I personally envision the Facade class
as the preferred way to obtain LoggerManagers from logger
package. The intent is to fill Facade with enough methods
to create all combinations of building blocks we'll need.
And failing to find what they need users will be able
to "construct" their own.

WBR, Anton

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message