[
https://issues.apache.org/jira/browse/LOG4J2-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534598#comment-17534598
]
Matt Sicker commented on LOG4J2-3497:
-------------------------------------
A bit of software archaeology will get you part of the way towards
understanding why PluginRegistry and PluginManager work the way they do. The
first commit of {{{}PluginRegistry{}}}:
[https://github.com/apache/logging-log4j2/commit/9b6fde933c2af73ab3998f381d46d4f4de194bce]
done by myself a little over 8 years ago. This obviously changed a bit over
time as we added the annotation processor (which initially replaced the main()
method in {{PluginManager}} which scanned the classpath using
{{{}ResolverUtil{}}}, though we re-added that via the packages configuration
option), OSGi support, and further caching. In general, though,
{{PluginRegistry}} was initially created to change plugins from a one-and-done
load event into a [whiteboard
pattern|https://en.wikipedia.org/wiki/Whiteboard_Pattern] to support plugins in
OSGi runtimes (where modules/bundles can be installed, updated, and uninstalled
at runtime).
>From the beginning, plugins have been a way to group together different
>categories of Java classes that are instantiated and configured in different
>ways, and {{PluginManager}} has been the class to obtain plugin metadata so
>that different subsystems could instantiate their plugins. Core plugins were
>introduced for core concepts like appenders, loggers, filters, etc., which are
>all configured in a config file, while other category plugins were typically
>defined for specific plugins (like PatternLayout and its converter key
>plugins; a plugin that has plugins, imagine that!) and eventually even for
>SPI-like plugins such as type converters. Keep in mind that the primary goal
>of plugins was to avoid requiring fully qualified class names in configuration
>files which I think we all agree would be poor UX.
When you look at the different categories of plugins that have existed, they've
usually fallen into three patterns:
* Core plugins which involve a tree of nodes to bind configuration options to
things
* Plugins that have a default constructor
* Plugins that use a common constructor signature or static method signature
which can be invoked reflectively without any complicated reflection logic to
find the method or constructor
Over time, I've added features to the plugin system sometimes to reduce code
duplication or where I identified clear patterns that could be neatly
refactored. It wasn't until sometime during 3.x development when I looked back
at the plugin system for cleanup (partly to rename the visitor classes to
something more appropriate) that I thought, huh, we have a lot of pieces of
what a dependency injection system has, but they weren't all speaking the same
language, so I made a few different attempts at unifying the plugin system with
DI.
Some of the desire for a DI system also came from times where a feature would
be introduced that didn't make sense to configure as a system property, but
would also be relevant to more than a single plugin instance and thus also
didn't make much sense as a configuration node (or would require an
accompanying special plugin like {{AppenderRef}} to allow for more graph-like
structure rather than a strict tree).
And one last tidbit: a large amount of refactoring that I've done over the
years has been around reducing code duplication, applying design patterns, and
some personal taste. From around the same time as {{PluginRegistry}} being
introduce, {{PluginBuilder}} was also added:
[https://github.com/apache/logging-log4j2/commit/e8388e6d69ab9d9fb8c790749b95950e15f5d7b7].
You can sort of see how things used to be grouped together into larger
classes. That got further split up into visitor strategies on how to handle
different annotations. Given enough time, we're now at the DI system.
> ConstraintValidator's are not employed by PluginManager
> -------------------------------------------------------
>
> Key: LOG4J2-3497
> URL: https://issues.apache.org/jira/browse/LOG4J2-3497
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
> Reporter: Volkan Yazici
> Assignee: Matt Sicker
> Priority: Major
> Fix For: 2.18.0
>
>
> {{ConstraintValidator}}'s are not taken into account when plugins are
> collected via {{PluginManager}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
