Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <410014040.1210347416636.JavaMail.jira@brutus>
Date: Fri, 9 May 2008 08:36:56 -0700 (PDT)
From: "Alexander Pogrebnyak (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (LOGGING-123) Add a LogLevel enum with the usual
 suspects (FATAL,ERROR,WARN,INFO,DEBUG,TRACE)
In-Reply-To: <371165554.1210261255691.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LOGGING-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Pogrebnyak updated LOGGING-123:
-----------------------------------------

    Description: 
It is sometimes convenient to setup logging level dynamically.

For example if you implement Command object pattern. Some of the command require very detailed in your face logging (say at INFO, or even WARN levels), for others DEBUG or even TRACE would do fine.

With the current methods on Log interface you either have to do it through different boolean settings, which quickly lead to a mess.

More elegant solution is to define a log level object and just examine it when doing logging.

here is the use case

{code:title=Sample Usage |borderStyle=solid}

final static Log LOGGER = ...;

public class Command
{
  final LogLevel _log_level;

  public Command ( final boolean is_logging_enabled )
  {
    LogLevel log_level = LogLevel.TRACE;

    if ( is_logging_enabled )
    {
      log_level = LogLevel.INFO;
    }

    if ( ! log_level.isEnabledIn( LOGGER ) )
    {
      log_level = null;
    } 

    _log_level = log_level;
  }

  public void doCommand ( )
  {
    if ( _log_level != null )
    {
      _log_level.log( LOGGER, "Running command" );
    }
  }
}
{code}

The proposed solution is all done through the inversion of control, so it does not require to change a single line in org.apache.commons.logging.Log interface, although it might be useful to add these 3 methods:

boolean isEnabledFor ( final LogLevel level );

void log ( final LogLevel level, final String message );

void log ( final LogLevel level, final String message, final Throwable t );

Attached is a full listing of proposed LogLevel.java


  was:
It is sometimes convenient to setup logging level dynamically.

For example if you implement Command object pattern. Some of the command require very detailed in your face logging (say at INFO, or even WARN levels), for others DEBUG or even TRACE would do fine.

With the current methods on Log interface you either have to do it through different boolean settings, which quickly lead to a mess.

More elegant solution is to define a log level object and just examine it when doing logging.

here is the use case

final static Log LOGGER = ...;

public class Command
{
  final LogLevel _log_level;

  public Command ( final boolean is_logging_enabled )
  {
    LogLevel log_level = LogLevel.TRACE;

    if ( is_logging_enabled )
    {
      log_level = LogLevel.INFO;
    }

    if ( ! log_level.isEnabledIn( LOGGER ) )
    {
      log_level = null;
    } 

    _log_level = log_level;
  }

  public void doCommand ( )
  {
    if ( _log_level != null )
    {
      _log_level.log( LOGGER, "Running command" );
    }
  }
}


The proposed solution is all done through the inversion of control, so it does not require to change a single line in org.apache.commons.logging.Log interface, although it might be useful to add these 3 methods:

boolean isEnabledFor ( final LogLevel level );

void log ( final LogLevel level, final String message );

void log ( final LogLevel level, final String message, final Throwable t );

Attached is a full listing of proposed LogLevel.java


Added markup for sample code formatting

> Add a LogLevel enum with the usual suspects (FATAL,ERROR,WARN,INFO,DEBUG,TRACE)
> -------------------------------------------------------------------------------
>
>                 Key: LOGGING-123
>                 URL: https://issues.apache.org/jira/browse/LOGGING-123
>             Project: Commons Logging
>          Issue Type: New Feature
>         Environment: N/A
>            Reporter: Alexander Pogrebnyak
>            Priority: Trivial
>         Attachments: LogLevel.java
>
>
> It is sometimes convenient to setup logging level dynamically.
> For example if you implement Command object pattern. Some of the command require very detailed in your face logging (say at INFO, or even WARN levels), for others DEBUG or even TRACE would do fine.
> With the current methods on Log interface you either have to do it through different boolean settings, which quickly lead to a mess.
> More elegant solution is to define a log level object and just examine it when doing logging.
> here is the use case
> {code:title=Sample Usage |borderStyle=solid}
> final static Log LOGGER = ...;
> public class Command
> {
>   final LogLevel _log_level;
>   public Command ( final boolean is_logging_enabled )
>   {
>     LogLevel log_level = LogLevel.TRACE;
>     if ( is_logging_enabled )
>     {
>       log_level = LogLevel.INFO;
>     }
>     if ( ! log_level.isEnabledIn( LOGGER ) )
>     {
>       log_level = null;
>     } 
>     _log_level = log_level;
>   }
>   public void doCommand ( )
>   {
>     if ( _log_level != null )
>     {
>       _log_level.log( LOGGER, "Running command" );
>     }
>   }
> }
> {code}
> The proposed solution is all done through the inversion of control, so it does not require to change a single line in org.apache.commons.logging.Log interface, although it might be useful to add these 3 methods:
> boolean isEnabledFor ( final LogLevel level );
> void log ( final LogLevel level, final String message );
> void log ( final LogLevel level, final String message, final Throwable t );
> Attached is a full listing of proposed LogLevel.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.