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.