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.

Reply via email to