Java provides standard way to load application extensions. See java.util.ServiceLoader. We can use it to avoid reinventing the wheel.
Look how java cache system detects CachingProvider classes: the jar that provides cache implementation registers his CachingProvider class name in /META-INF/services/javax.cache.spi.CachingProvider file. Then cache provider will be found automatically using java.util.ServiceLoader. Ignite may detect plugin providers same way. User will not need to describe each plugin in configuration, adding plugin jar to classpath will be enough. But this approach requires total refactoring of Ignite plugin system. On Fri, Apr 3, 2015 at 5:52 PM, Artiom Shutak <[email protected]> wrote: > Hi, > > I hope it's not too late to change public API of the Ignite Plugin feature. > > I have next suggestions: > 1. PluginConfiguration interface have only one method > > Class<? extends PluginProvider> providerClass(); > > and we have processing code, which try to instantiate PliginProvider with 3 > types of constructors (in this order): constructor with PluginContext as > parameter, constructor with PluginConfiguration as parameter and default > constructor. > It seems to me that there is no a reason for user to don't apply already > created PluginContext, which have all needed information. I suggest another > method > > PluginProvider createProvider(PluginContext ctx); > > I additional, I want to note that if user want to create own plugin then he > has to extend PluginConfiguration (there is no way to implement just > PluginProvider without PluginConfiguration). > > 2. PluginContext suggestions > > - "configuration" method (return PluginConfiguration) rename to > "pluginConfiguration"; > - "grid" method (return Ignite) rename to "ignite" > - to delete next methods, because all of them can be gotten from > Ignite: igniteConfiguration, nodes, localNode, log. > > > -- Artem -- >
