avalon-excalibur/logger refactoring

[Anton Tagunov <at...@mail.cnt.ru>]

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
    avalon-excalibur/logger/src/java/o/a/a/e/logger/Facade.java
and proceed to
    avalon-excalibur/logger/src/java/o/a/a/e/logger/logkit/*.java
    avalon-excalibur/logger/src/java/o/a/a/e/logger/log4j/*.java
    avalon-excalibur/logger/src/java/o/a/a/e/logger/decorators/*.java

    
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

Re: avalon-excalibur/logger refactoring

[Berin Loritsch <bl...@apache.org>]

Anton Tagunov wrote:
> Hello Berin,
> 
> 
> BL> I'm glad you are taking on the task of making it work well.
> BL> That's a good thing.  Please do keep in mind that this
> BL> package is used by more than one project, so please make
> BL> sure that we have backwards compatibility.
> 
> :-)
> 
> A quick answer: I do keep that in mind!
> No backward compat breakage :-)
> 
> How about the code itself?

I need to look into it more deeply...



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

Re[2]: avalon-excalibur/logger refactoring

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Berin,


BL> I'm glad you are taking on the task of making it work well.
BL> That's a good thing.  Please do keep in mind that this
BL> package is used by more than one project, so please make
BL> sure that we have backwards compatibility.

:-)

A quick answer: I do keep that in mind!
No backward compat breakage :-)

How about the code itself?

- Anton


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

Re: avalon-excalibur/logger refactoring

[Berin Loritsch <bl...@apache.org>]

Anton Tagunov wrote:
> 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
>     avalon-excalibur/logger/src/java/o/a/a/e/logger/Facade.java
> and proceed to
>     avalon-excalibur/logger/src/java/o/a/a/e/logger/logkit/*.java
>     avalon-excalibur/logger/src/java/o/a/a/e/logger/log4j/*.java
>     avalon-excalibur/logger/src/java/o/a/a/e/logger/decorators/*.java
> 
>     
> 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

<snip/>

I'm glad you are taking on the task of making it work well.
That's a good thing.  Please do keep in mind that this
package is used by more than one project, so please make
sure that we have backwards compatibility.

There is nothing wrong with clarifying some issues in the
classes, but if we change classnames, etc. we need to make
sure that the LoggerManager stuff still works.

Cocoon uses it, so when you are done with your refactoring
work, I'd like to test dropping it in Cocoon to make sure
nothing breaks.


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