ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Ignite Plugin public API
Date Fri, 03 Apr 2015 18:05:01 GMT
On Fri, Apr 03, 2015 at 08:18PM, Vladimir Ozerov wrote:
> -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.

While the rest of your points are pretty valid, IMO, I'd say that guessing a
user intention might not work as well as anticipated. If a user messed up and
have two plugins of the conflicting nature setup - let him deal with the
consequences. 

"Unix gives you enough rope to hand yourself and then a couple more feet to make sure"

Cos

> 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 <sevdokimov@gridgain.com>
> 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 <ashutak@gridgain.com>
> > 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 --
> > >
> >

Mime
View raw message