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.
Issues in Epic
|LOG4J2-858||Improve PluginManager to filter plugins by class||Open||Unassigned|
||LOG4J2-860||Unify plugin builders and plugin factories||Resolved||Matt Sicker|
|LOG4J2-1317||Add ability for lookups to use defaults for other values than null||Open||Ralph Goers|
|LOG4J2-1531||Change attribute and component values from String to Object||Open||Ralph Goers|
|LOG4J2-1898||Update classes in org.apache.logging.log4j.core.net.ssl to the builder pattern||Open||Unassigned|
||LOG4J2-2040||Clarify how to include plugin .dat file in OSGi bundle based Log4j plugins||Resolved||Unassigned|
|LOG4J2-2419||Clean API to get all loggers at runtime||Open||Unassigned|
|LOG4J2-2458||Log4j2 does not load @Plugin annotated Kotlin classes||Open||Unassigned|
|LOG4J2-2590||Improve programmatically API documentation||Open||Unassigned|
|LOG4J2-2600||Declarative Groovy Configuration DSL||Open||Matt Sicker|
|LOG4J2-2604||Generate reflect-config.json for GraalVM during annotation processing||Open||Unassigned|
||LOG4J2-2607||How to add Log4J2 appenders at runtime programmatically?||Closed||Unassigned|
|LOG4J2-2670||Add an option to customize the ObjectMapper for JSONLayout||Open||Unassigned|
||LOG4J2-2693||@PluginValue does not support attribute names besides "value"||Resolved||Matt Sicker|
||LOG4J2-2700||Add support for injecting plugin configuration via builder methods||Resolved||Matt Sicker|
||LOG4J2-2702||Unify @Plugin, @PluginFactory, and @PluginBuilderFactory annotations||Closed||Matt Sicker|