[
https://issues.apache.org/jira/browse/LOG4J2-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-3474.
---------------------------------
Fix Version/s: 3.0.0
Assignee: Matt Sicker
Resolution: Fixed
Resolving this issue as it relates to a changelog entry I added for the DI
system (which has the name {{{}ConfigurableInstanceFactory{}}}, not
{{{}PluginBuilder{}}})
> Use PluginBuilder for instantiating plugins
> -------------------------------------------
>
> Key: LOG4J2-3474
> URL: https://issues.apache.org/jira/browse/LOG4J2-3474
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
> Reporter: Volkan Yazici
> Assignee: Matt Sicker
> Priority: Major
> Fix For: 3.0.0
>
>
> There are various places in the source code (in particular, Pattern and JSON
> Template layouts) where plugins are extensively used. There plugins are
> discovered via {{PluginManager}} but instantiated using some custom logic
> afterwards. This approach has serious caveats:
> * Code duplication
> * {{ConstraintValidator}} checks (e.g., {{{}RequiredClass{}}}) are ignored
> * Injection is ignored
> * All other {{PluginBuilder}} checks and functionalities are discarded and
> this breaks the plugin contract
> All plugins should rather be instantiated using {{{}PluginBuilder{}}}.
> This flaw also hints us that the developer-facing API of plugins is severely
> convoluted to the point of maintainers cannot simply discover-and-load a
> plugin without making a mistake. {{PluginUtil}} was an attempt to improve
> this situation, though it first needs to be used by the rest of the code base
> and it also suffers from the above custom instantiation logic shortcoming.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
