[
https://issues.apache.org/jira/browse/LOG4J2-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520755#comment-17520755
]
Matt Sicker commented on LOG4J2-3474:
-------------------------------------
Note that this has generally been addressed by the new DI system in 3.x as all
plugins are instantiated via {{Injector}} now which replaces
{{{}PluginBuilder{}}}. If you want to refactor 2.x such that plugin
instantiation is centralized through {{{}PluginBuilder{}}}, that could be
useful, too, though that mainly adds support for injecting {{@Plugin~}}
annotations from config nodes. I should note that while I was working on the DI
changes, I initially replaced all invocations of {{new PluginManager}} with
calls to {{PluginUtil}} which made it easier to refactor and eventually remove
that class once {{PluginManager}} was sufficiently integrated into Injector
directly; refactoring 2.x to likewise use {{PluginUtil}} instead seems like a
good idea toward maintaining consistency (and potentially making reuse of
{{PluginBuilder}} et al easier there).
> 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
> Priority: Major
>
> 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.1#820001)