ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Ignite Plugin public API
Date Fri, 03 Apr 2015 16:02:04 GMT

Given none has yet started implementing plugins for Ignite, I think we can
do it.

I agree with both points.

1. Why we force user to have constructors we want? Will not it be simpler
just return instantiated and configured provider? Jcache uses similar
approach with its factories.
2. We can remove 4 methods from context, since everything is available via
Ignite - Ignite.log(); Ignite.cluster().localNode();
Ignite.configuration(); etc



2015-04-03 17:52 GMT+03:00 Artiom Shutak <ashutak@gridgain.com>:

> 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 --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message