[
https://issues.apache.org/jira/browse/LOG4J2-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17543532#comment-17543532
]
Matt Sicker commented on LOG4J2-3496:
-------------------------------------
So I added more container factory injection support, though I see that most of
the remaining direct usage of PluginNamespace would require changing their APIs
a bit to use native dependency injection rather than their ad hoc methods of
instantiation. Specifically:
* BuilderManager in log4j-1.2-api checks for a constructor with {{String}} and
{{Properties}} parameters.
* Core plugins already have custom handling due to being configurable
* Level plugins get loaded just by making sure their plugin classes have
loaded as those tend to construct {{Level}} instances which self-register
* PatternConverter plugins look for a static method named {{newInstance()}}
with a couple options of detectable signatures
* Watcher plugins use a constructor with parameters {{{}Configuration{}}},
{{{}Reconfigurable{}}}, {{{}List<ConfigurationListener>{}}}, and {{long}}
* ConfigurationFactory plugins use a different sorting annotation which has to
be checked before creating them; if this were migrated to the new standardized
annotation, then this could just inject {{List<ConfigurationFactory>}}
> Support injection via container types
> -------------------------------------
>
> Key: LOG4J2-3496
> URL: https://issues.apache.org/jira/browse/LOG4J2-3496
> Project: Log4j 2
> Issue Type: New Feature
> Components: Plugins
> Reporter: Volkan Yazici
> Assignee: Matt Sicker
> Priority: Major
> Fix For: 3.0.0
>
>
> Plugin system should support the injection via container types. Since this is
> not currently the case, whenever a, for instance, collection of plugins need
> to be injected (e.g., Pattern and JSON Template Layouts), ad-hoc access to
> {{PluginManager}} or {{PluginUtils}} is needed. This approach has certain
> drawbacks:
> * Duplication of ad-hoc code
> * Not aligned with the way plugins are loaded, that is, via {{@Inject}}
> * Impossible to test
> h3. Container types
> Ideally, the plugin system should support injection via the following
> container types:
> * {{Optional<P>}}
> * {{Collection<P>}}
> * {{Iterable<P>}}
> * {{Set<P>}}
> * {{Stream<P>}}
> * {{List<P>}}
> * {{Map<N, P>}}
> Above {{P}} denotes the type the plugin is assignable from and {{N}} denotes
> the plugin name.
> h3. Ordering problem
> A {{@PluginOrder}} annotation needs to be introduced to address the following
> corner cases:
> * In the case of {{Optional<P>}}, if there are multiple matches, the first
> one needs to be picked.
> * In the case of collection and map types, elements need to be sorted.
> Sorting can be done in the following way:
> * If one or more of the matches are annotated with {{@PluginOrder}}, they
> will have the precedence and get sorted according to {{@PluginOrder}} values.
> * The rest will be sorted according to their discovery order.
> The order in collection types can be preserved using the following
> implementations:
> * {{Set}} -> {{LinkedHashSet}}
> * {{Map}} -> {{LinkedHashMap}}
> * {{Collection}}, {{Iterable}}, {{Stream}} -> {{List}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
