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

["Matt Sicker (Jira)" <ji...@apache.org>]

    [ 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)