Configuration of the logger used internally by LoggerManagers.

[Leif Mortenson <le...@tanukisoftware.com>]

I am running into a problem while organizing the log output of Fortress.

I would like to allow the user to configure the logger to be used by the 
LogKitLoggerManager
for its output.  In the case of fortress, that would be "fortress.logkit"

I can do that by creating the LogKitLoggerManager as follows.
            org.apache.log.Logger lmLogger = hierarchy.getLoggerFor( 
"logkit" );
            LogKitLoggerManager logManager = new LogKitLoggerManager(
                "fortress", hierarchy, new LogKitLogger( lmLogger ) );

The problem with this approach is that the defaultLogger will be set to 
"fortress.logkit".
I would really like to be able to set it to "fortress".   This makes it 
very easy to configure
the logger so that all LoggerManager related output is disabled, while 
at the same time
be able to see the output of classes making use of the defaultLogger.

There are two possible solutions.
1) Create a additional constructor which takes a 4th argument:
    public LogKitLoggerManager( final String prefix, final Hierarchy 
hierarchy,
        final Logger defaultLogger, final Logger logger )
    {
        m_prefix = prefix;
        m_hierarchy = hierarchy;
        m_defaultLogger = defaultLogger;
        m_logger = logger;
    }
    This is the approach that I prefer as it enables me to set the 
internal logger to the default value
    to maintain compatability.

2) Modify either LoggerManager or the individual implementations to 
implement LoggedEnabled
    the calling code would then call enableLogging like any other object 
to set the internal logger.
    Once again for backwards compatability, the internal logger would be 
set to the default
    logger by default.  This has the risk of getting some different 
functionality if the instance passes
    though any container code which does an if instanceof LoggedEnabled 
test.

Cheers,
Leif




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Configuration of the logger used internally by LoggerManagers.

[Leif Mortenson <le...@tanukisoftware.com>]

No comments on this and I need to proceed, so I'll hope it doesn't cause 
any pain and move
forward with option #1,  I will only apply this to the 
LogKitLoggerManager for now.  But it should
also be applied to the Log4JLoggerManager as well

As a note, I never use Log4J with Avalon.  But this built using 
log4j-1.1.3.jar, but fails
using log4j-1.2.6.jar.   I get a host of compiler errors.  This may be a 
known issue??

Cheers,
Leif



Leif Mortenson wrote:

> I am running into a problem while organizing the log output of Fortress.
>
> I would like to allow the user to configure the logger to be used by 
> the LogKitLoggerManager
> for its output.  In the case of fortress, that would be "fortress.logkit"
>
> I can do that by creating the LogKitLoggerManager as follows.
>            org.apache.log.Logger lmLogger = hierarchy.getLoggerFor( 
> "logkit" );
>            LogKitLoggerManager logManager = new LogKitLoggerManager(
>                "fortress", hierarchy, new LogKitLogger( lmLogger ) );
>
> The problem with this approach is that the defaultLogger will be set 
> to "fortress.logkit".
> I would really like to be able to set it to "fortress".   This makes 
> it very easy to configure
> the logger so that all LoggerManager related output is disabled, while 
> at the same time
> be able to see the output of classes making use of the defaultLogger.
>
> There are two possible solutions.
> 1) Create a additional constructor which takes a 4th argument:
>    public LogKitLoggerManager( final String prefix, final Hierarchy 
> hierarchy,
>        final Logger defaultLogger, final Logger logger )
>    {
>        m_prefix = prefix;
>        m_hierarchy = hierarchy;
>        m_defaultLogger = defaultLogger;
>        m_logger = logger;
>    }
>    This is the approach that I prefer as it enables me to set the 
> internal logger to the default value
>    to maintain compatability.
>
> 2) Modify either LoggerManager or the individual implementations to 
> implement LoggedEnabled
>    the calling code would then call enableLogging like any other 
> object to set the internal logger.
>    Once again for backwards compatability, the internal logger would 
> be set to the default
>    logger by default.  This has the risk of getting some different 
> functionality if the instance passes
>    though any container code which does an if instanceof LoggedEnabled 
> test.
>
> Cheers,
> Leif
>
>
>
>
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>