You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2014/08/06 07:21:13 UTC

[jira] [Updated] (LOG4J2-589) Allow the use of custom levels in configuration

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

Remko Popma updated LOG4J2-589:
-------------------------------

    Description: 
Previous title: Use forName instead of getLevel and valueOf for configuration

Without this one cannot use custom log levels in configuration without forking a large amount of code.  Either the forName method needs to be removed and custom log levels should be explicitly forbidden, or support should be consistent.
Classes that would need to be modified:
BaseConfiguration, NullConfiguration, and DefaultConfiguration.

  was:
Without this one cannot use custom log levels in configuration without forking a large amount of code.  Either the forName method needs to be removed and custom log levels should be explicitly forbidden, or support should be consistent.
Classes that would need to be modified:
BaseConfiguration, NullConfiguration, and DefaultConfiguration.

        Summary: Allow the use of custom levels in configuration  (was: Use forName instead of getLevel and valueOf for configuration)

Configuration elements like Logger and AppenderRef that accept a Level attribute will use a {{LevelConverter}} (subclass of {{TypeConverter}}) to convert the specified string to a {{Level}} instance.

LevelConverter uses {{Level.valueOf(str)}} to do the conversion. The {{valueOf}} method will return a custom level instance if it exists, but throws an exception if not. So the configuration fails if it encounters custom levels that have not been registered yet. 

Registration is done with the {{Level.forName(String name, int intValue)}} method. The {{intValue}} is necessary to determine  where the custom level exists in relation to the built-in levels. (This is now [better documented|http://logging.apache.org/log4j/2.x/manual/customloglevels.html].)

I need to think a little about how to improve this. Perhaps configuration could have a custom levels section? For example:
{code}
<Configuration status="warn">
  <!-- just an idea -->
  <CustomLevels>
    <Level name="DIAG" intLevel="350" />
    <Level name="NOTICE" intLevel="450" />
    <Level name="VERBOSE" intLevel="550" />
  </CustomLevels>
  ...
{code}

As a workaround, you can manually register your custom levels before the configuration is loaded. One way to achieve this is to have a static initializer block in the first class that uses log4j2 loggers (or a class that is loaded before that):
{code}
static {
    // register custom log levels before log4j2 configuration is loaded
    Level.forName("DIAG", 350);
    Level.forName("NOTICE", 450);
    Level.forName("VERBOSE", 550);
}
{code}


> Allow the use of custom levels in configuration
> -----------------------------------------------
>
>                 Key: LOG4J2-589
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-589
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Configurators
>    Affects Versions: 2.0-rc1
>            Reporter: James Hutton
>              Labels: configuration, custom, level
>
> Previous title: Use forName instead of getLevel and valueOf for configuration
> Without this one cannot use custom log levels in configuration without forking a large amount of code.  Either the forName method needs to be removed and custom log levels should be explicitly forbidden, or support should be consistent.
> Classes that would need to be modified:
> BaseConfiguration, NullConfiguration, and DefaultConfiguration.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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