Page History

...

This proposal is to require all properties to follow a more well defined structure. The proposal for the structure of a Log4j 2 property is log42.{LoggerContextName}.{ComponentName}.{property}. To keep the documentation from becoming a mess the current properties in 2.x would NOT be supported in 3.0.

The LoggerContext has always been allowed to have a name. it currently is internally generated and used as the unique key to locate it based on its associated ClassLoader. This is unfortunate as there are cases where users would like to specify properties that apply only to a specific LoggerContext. This proposal would create a new private LoggerContext field named contextKey that is used in place of the contextName as the key in the LoggerContext Map. The various API layers would be modified to accept a contextName field when he LoggerContext is created. The context name will be immutable.

...

Note that JsonTemplateLayout includes a JsonReader. If that is moved into log4j-core we should be able to support JSON configuration and properties without any additional dependencies.  In addition, our Spring Boot support will allow the user to specify the JSON below in the application's bootstrap.yml file as an alternative to log4j2.component.properties and log4j2.component.yml.

{ "log4j2": {
    "My-App": {
      "JNDI": {
        "enableJMS": "true"
      }
      "Script": {
        "enableLanguages": [
	      "Groovy",
          "JavaScript"		
		]
      }
      "Configuration": {
        "mergeStrategy": "com.acme.log4j.CustomMergeStrategy",
        "location": "classpath:log4j2-My-App.xml",
        "statusLoggerLevel": "debug"
      }
   },       "*":  {
            "StatusLogger": {
                "defaultStatusLevel": "Info"
            }
       }}

...