spring.sbp.custom-plugin-loaders and pluginRepository

[fabioformosa]

I've tried the prop in application-context spring.sbp.custom-plugin-loaders.
It appends custom loaders to the list of pre-existing loaders. So custom loaders can't apply for files with extension .zip or .jar, because the loading is prevented by pre-existing loaders.
So the custom loader should apply for files with different extension, but it's not possible, because the file discovering is accomplished by fileFilter in PluginRepository and there is no way to add custom pluginRepository.

Could you allow to set plugin repositories as you done with plugin loaders?

Let me say my opinion: maybe It's too limited to customize the SpringBootPluginManager only through properties in application.yml. The force of pf4j is the high grade of customization by class inheritance. Why is it not possible to extend your SpringBootPluginManager and declare it as bean preventing the creation in the sbp library? after all there is a @ConditionalOnMissingBean in SbpAutoConfiguration.

[hank-cp]

Make sense. Have made custom-plugin-loader exclusive.

I will think about refactoring SpringBootPluginManager to some kind of builder.

[hank-cp]

Let me say my opinion: maybe It's too limited to customize the SpringBootPluginManager only through properties in application.yml. The force of pf4j is the high grade of customization by class inheritance. Why is it not possible to extend your SpringBootPluginManager and declare it as bean preventing the creation in the sbp library? after all there is a @ConditionalOnMissingBean in SbpAutoConfiguration.

not an easy work. pf4j is designed in old school OOP principal and make it kinds of hard to be extent and customized (comparing to IOC framework like spring). For example, to extend SpringBootPluginManager.createPluginStatusProvider(), I need extra parameters but it's called in super(), where I have totally not chance to provide those extra parameters. That's why I make SpringBootPluginManager an anonymous class in SbpAutoConfiguration so it could access extra parameters in host class context. Some time I even have to hack pf4j via refection. pf4j is good enough so far, not sill have some limitation to achieve next level goas like "plugin repository".