A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://apacheignite-net.readme.io/docs/plugins below:

Plugins

Ignite.NET plugin system allows third parties to extend the core Ignite.NET functionality.

The best way to explain how Ignite plugins work is by looking at the life cycle of plugins.

First, an Apache Ignite plugin has to be registered via the IgniteConfiguration.PluginConfigurations property which is a collection of IPluginConfiguration implementations. From a user's perspective, this is a manual process - a plugin's assembly has to be referenced and configured explicitly.

IPluginConfiguration interface has two members that interact with the Java part of Apache Ignite.NET. This is described in the next section. Besides those two members, IPluginConfiguration implementation should contain all the other plugin-specific configuration properties.

Another part of an IPluginConfiguration implementation is the mandatory [PluginProviderType] attribute that links a plugin configuration to a plugin implementation. For example:

[PluginProviderType(typeof(MyPluginProvider))]
    public class MyPluginConfiguration : IPluginConfiguration
    {
        public string MyProperty { get; set; }  // Plugin-specific property

        public int? PluginConfigurationClosureFactoryId
        {
            get { return null; }  // No Java part
        }

        public void WriteBinary(IBinaryRawWriter writer)
        {
            // No-op.
        }
    }

Summary:

IPluginProvider implementation is the work-horse of the newly added plugin. It deals with the Ignite node life cycle by processing the calls to OnIgniteStart and OnIgniteStop methods. In addition, it can provide an optional API to be used by an end user via the GetPlugin<T>() method.

The first method to be invoked on the IPluginProvider implementation by the Ignite.NET engine is Start(IPluginContext<TestIgnitePluginConfiguration> context). IPluginContext provides an access to an initial plugin configuration and all means to interact with Ignite.

When Ignite is being stopped, Stop and OnIgniteStop methods are executed sequentially so that the plugin implementation can accomplish all cleanup and shutdown-related​ tasks.

Plugins can expose user-facing API which is accessed via the IIgnite.GetPlugin(string name) method. The Ignite engine will search for IPluginProvider with the passed name and call GetPlugin on it.

Ignite.NET plugin can interact with Ignite Java plugin via the PlatformTarget & IPlatformTarget interface pair.

On the Java side:

class MyPluginTarget implements PlatformTarget {
  @Override public long processInLongOutLong(int type, long val) throws IgniteCheckedException {
    if (type == 1)
    	return val + 1;
    else
      return val - 1;
  }
  ...  // Other methods here.
}
public class MyPluginExtension implements PlatformPluginExtension {
  @Override public int id() {
    return 42;  // Unique id to be used from .NET side.
  }

  @Override public PlatformTarget createTarget() {
    return new MyPluginTarget();  // Return target from previous step.
  }
}
@Override public void initExtensions(PluginContext ctx, ExtensionRegistry registry) {
  registry.registerExtension(PlatformPluginExtension.class, new MyPluginExtension());
}

On the .NET side:

IPlatformTarget extension = pluginContext.GetExtension(42);

long result = extension.InLongOutLong(1, 2);  // processInLongOutLong is called in Java

Other IPlatformTarget methods provide an efficient way to exchange any kind of data between Java and .NET code.

Callbacks from Java

.NET -> Java call mechanism is described above; you can also do Java -> .NET calls:

👍

Plugin Example

Detailed walk-through and a working plugin example can be found in the blog post.

Updated over 4 years ago


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4