-1 for automatic plugin detection. My concerns: a) Different plugins might provide overlapping features and it is necessary to decide which service will be provided by which provider. b) Plugins participate in node lifecycle and relative start/stop order might be important as well. E.g. when there are two plugins from the same vendor and there is a requirement that one plugin must be started before another. c) Every plugin most likely will have configuration, so something "explicit" will be required anyway. d) Last, but not least - this approach is prone to "jar hell" issues typical for app servers.
On Fri, Apr 3, 2015 at 7:11 PM, Sergey Evdokimov <[email protected]> wrote: > 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 -- > > >
