[LOG4J2-2694] Enhance plugin system to support old config formats and more flexible code bindings

• Type: Epic
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: Configurators, Core, Plugins
• Epic Name: Plugin Ergonomics
• Assignee: Matt Sicker
• Reporter: Matt Sicker
• Created: 16/Sep/19 21:06
• Updated: 07/Mar/20 17:19

Description

The overarching goal of this epic is to upgrade the plugin and configuration system to accomplish the following:

• Make a simpler API to instantiate plugins
• Unify the plugin instantiation API between the different categories
• Allow for multiple configuration input mappings to be defined for a plugin (more advanced that just aliases; this should support Log4j 1.x, 2.x, and 3.x config files to all map to 3.x plugins).
• Support node attributes and values besides strings (originally optimized around XML/properties limitations) to more easily allow for more types from other configuration formats like in LOG4J2-2600.
• Plugin configuration dependency injection via @PluginAttribute et al. should support method-based injection so that the setters/withers/etc. can define their own custom validation directly on the property rather than relying on build() doing all the static validation.
• Make the plugin validation annotations easier to insert statically.
• Reduce the code duplication in the various ConfigurationFactory and Configuration implementations. This should go hand in hand with support for additional configuration file formats (see LOG4J2-2600 for example).

Some potential ideas to explore:

• Refactor Configuration to be a plugin. This could be a way to greatly reduce code duplication in the above ideas.
• Support some sort of API bridge for plugins written against the 1.x or 2.x APIs. This could be a static bridge as has been developed already, or some sort of dynamic solution can be investigated. Supporting configuration files for 1.x and 2.x is already a great starting point for easy migrations.
• Expose plugin metadata in an API. This might be useful for building a UI for creating or manipulating a configuration file. This would likely be useful for many other frameworks that wish to have a more standardized way to interact with the running plugin system.
• Provide better support for programmatic configuration where various plugin instances are manually instantiated rather than via reflection through the 2.x plugin system. This would be particularly useful for static configurations written as code for microservice and serverless deployments where startup time is an important performance factor.

Issue Links

• relates to: LOG4J2-2803 Create standardized scopes and dependency injection API