[
https://issues.apache.org/jira/browse/LOG4J2-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17043105#comment-17043105
]
Matt Sicker commented on LOG4J2-2694:
-------------------------------------
See the {{mean-bean-machine}} branch for a work in progress related to this.
> Enhance plugin system to support old config formats and more flexible code
> bindings
> -----------------------------------------------------------------------------------
>
> Key: LOG4J2-2694
> URL: https://issues.apache.org/jira/browse/LOG4J2-2694
> Project: Log4j 2
> Issue Type: Epic
> Components: Configurators, Core, Plugins
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Priority: Major
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
