Hello, I am doing some investigation on how to replace statically bound JsonTemplateLayout resolvers with plugins. For inspiration I was looking at PatternLayout and found the following: PatternLayout calls PatternParser ctor, which performs the following:
final PluginManager manager = new PluginManager(converterKey); manager.collectPlugins(config == null ? null : config.getPluginPackages()); final Map<String, PluginType<?>> plugins = manager.getPlugins(); final Map<String, Class<PatternConverter>> converters = new LinkedHashMap<>(); for (final PluginType<?> type : plugins.values()) { try { @SuppressWarnings("unchecked") final Class<PatternConverter> clazz = (Class<PatternConverter>) type.getPluginClass(); if (filterClass != null && !filterClass.isAssignableFrom(clazz)) { continue; } This got me really puzzled. I was expecting matched plugins to be injected into the @PluginFactory ctor of PatternLayout as a parameter of type List<PatternConverter> like every other DI system out there. That is, @PluginFactory AwesomeLayout( @PluginConfiguration Configuration config, @PluginElement("converters") List<PatternConverter> converters) { // ... } I find usage of PluginManager::new an anti-pattern. For one, it is not possible to unit test Pattern{Layout,Parser} by injecting only an isolated set of converters. Second, it is not possible to mock PluginManager either. Is injection of plugins extending a certain interface/class as a @PluginFactory ctor parameter something we can introduce to the plugin system? Kind regards.