[
https://issues.apache.org/jira/browse/LOG4J2-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532861#comment-17532861
]
Volkan Yazici commented on LOG4J2-3496:
---------------------------------------
{quote}I don't see how the injection system can be used with
PatternLayout{quote}
Imagine how you would do this if it would have been a Spring application. In
the current situation, {{PatternLayout}} creates a {{PatternParser}} which
internally collects {{PatternConverter}}'s via direct call to
{{PluginManager}}. With the proposed enhancement, {{PatternLayout}} builder
accepts a {{PatternParserFactory}} instead and that {{PatternParserFactory}}
has a builder containing a field of type {{Map<String, PatternConverter>}}.
Here the plugin infra populates {{PatternConverter}}'s, uses it to create a new
{{PatternParserFactory}}, and uses it to create a {{PatternLayout}}.
{quote}PatternParser runs through all the PatternConverter plugins and adds
them to a Map with the pattern converter symbol as the key and the converter
Class as the value. It then parses the pattern and creates a list of
PatternConverters in the order they are specified in the input.{quote}
Exactly and there is no way of changing this behavior, since it is hardcoded.
That is whole point of inversion-of-control (IoC) Ralph, right? You separate
the concerns of constructing objects and using them.
{quote}If all you are thinking of doing is the mapping from the plugins into
the Map of keys to converters, well ok. But I don't see a huge amount of value
in that.{quote}
The whole point of this practicing IoC throughout the entire code base,
whenever necessary. I am not telling every single spot using {{Instant.now()}}
should be first injected an {{Instant}} and use that. All I am saying is
plugins are there for IoC and should be used with that in mind. If random
components circumvent the plugin mechanism and indirectly access to that... It
is like a Spring bean creating its own {{ApplicationContext}} and using it to
populate its own dependencies. I don't know how else to make this more clear.
> 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)
