Log4j 2 2.x uses the PropertiesUtil class in log4j-api to access properties. It was enhanced in Log4j 2.10.0 to "normalize" property names. While this helped, with the growth in the number of properties Log4j uses managing them is getting harder.
We also desire to be able to have components enabled or disabled by default but to provide settings to override the default. With Log4j 2 3.x being much more modularized enablement of many things can be controlled simply by the presence of the jar that contains the relevant functionality. However, it is sometimes the case that we will want individual plugins to require specific enablement to be activated. The structure (or lack of) the current set of properties makes this difficult.
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}.
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.
This will allow a configuration like the one shown below. log4j2 at the top level identifies the file as containing log4j properties. The element at the next level down is the name of the LoggerContext the enclosed properties apply to. Within that properties are grouped by the components they apply to. Note that the term "component" is used loosely here.
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.
Code Block |
---|
{ "log4j2": { "My-App": { "Jms": { "enableJndi": "true" } "Script": { "enableLanguages": [ "Groovy", "JavaScript" ] } "Configuration": { "mergeStrategy": "com.acme.log4j.CustomMergeStrategy", "location": "classpath:log4j2-My-App.xml", "statusLoggerLevel": "debug" } } } |
Of course, the equivalent would also be available as properties, although the property names will change from their current values
Code Block |
---|
log4j2.My-App.Jms.enableJndi=true log4j2.My-App.Script.enableLanguages=Groovy,Javascript log4j2.My-App.Configuration.mergeStrategy=com.acme.log4j.CustomMergeStrategy log4j2.My-App.Configuration.location=classpath:log4j2-My-App.xml log4j2.My-App.Configuration.statusLoggerLevel=debug |
Using this format allows restrictions to be placed on plugins
Code Block |
---|
@RequireProperty(component = "Lookup", property = "enableJndi", value = "true") @Plugin(name = "jndi", category = StrLookup.CATEGORY) public class JndiLookup extends AbstractLookup {} |
This would prevent the Plugin from being loaded unless the requirement is met.
In the case of Scripting we would want the ScriptManager to be disabled unless one or more scripting language are enabled. In the case of the ScriptManager it is loaded by the ScriptManagerFactory in Log4j 2 3.x, which is loaded via ServiceLoader. The ScriptManager then locates all the ScriptEngines it can find. Each engine identifies the scripting languages it supports. If a matching language isn't specified in the properties than that engine would be discarded.