[
https://issues.apache.org/jira/browse/LOG4J2-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533349#comment-17533349
]
Matt Sicker commented on LOG4J2-3496:
-------------------------------------
Part of defining this feature is defining the semantics of bean declaration. As
it stands now, the {{@Plugin}} annotation is mainly used for giving aliases to
classes. Different categories of plugins may or may not wish to load all plugin
classes let alone instantiate them and inject dependencies. Core plugins, for
example, are only loaded and injected on-demand when referenced in a
configuration node, while most other plugin categories define injectable
classes that may or may not be instantiated on demand and referred to by name.
Converter key plugins load the classes but defer instantiation until parsing a
pattern string. The most consistent way to support arbitrary plugin injection
is to make {{PluginType<T>}} injectable along with adding some sort of
type-closure-based bean lookup. That can also potentially support injecting
{{Map<String, Key<? extends T>>}} for some base type {{{}T{}}}, which can still
be used later to get instances for the keys (or use {{Class}} instead of
{{{}Key{}}}). I can try adding a general way to inject collections of
injectable plugins, though it may need to use a qualifier on the collection to
denote the plugin category to get injectable instances from.
Making {{Optional<T>}} injectable is a great idea and is something I had in a
previous iteration but hadn't gotten around to re-adding in the current
version. That one is straightforward semantically.
> 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)
