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