[ 
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.

Reply via email to