Plugin configuration

[kwaclaw]

Given the example of an SSL plugin, ICE is prescribing which configuration properties are legal to use (for IceCS these are defined in PropertyNames.cs).

However, they are not of much use when working with a platform where OpenSSL is not the established way. Could there be a way that the plugin passes a list of suitable property names to Ice?

This could be done in Ice.Plugin.create() before the plugin class is instantiated, but it would require some changes in Communicator so that some properties can be loaded later.

Another option would be not to prescribe such properties at all and leave them to the plugin to load. In .NET there is an established way to do that (the System.Configuration classes), so it is not that much work.

Karl

[mes]

Hi,

The Ice run time only validates the properties that are defined by the Ice implementation. The C++ and Java SSL plugins use different properties, but all of them are validated because they might appear in the same configuration file.

I think you can reasonably expect that ZeroC will eventually implement an SSL plugin for C#, and we will call it IceSSL. Therefore it's not a good idea for a third-party implementation to use this name. Using your own property prefix, you will not have to worry about the Ice run time's property validation, and your plugin can validate its configuration however it wishes.

Take care,
- Mark

[kwaclaw]

I think you can reasonably expect that ZeroC will eventually implement an SSL plugin for C#, and we will call it IceSSL. Therefore it's not a good idea for a third-party implementation to use this name. Using your own property prefix, you will not have to worry about the Ice run time's property validation, and your plugin can validate its configuration however it wishes.

OK, good to hear that *eventually* you are going to provide one.

Here at work I want to build a small demo chat app to show that ICE works, as I am not as impressed with all that SOA buzz word frenzy.

I feel I need to show that ICE (for C#) can be secure, that is why I am going ahead with my own plugin.

Anyway, I will use the .NET configuration framework then.
That has just one disadvantage - I cannot pass my own properties object to the plugin factory since ICE does not provide for such a hook. This means I need to load the plugin first, and then configure it. Now the problem is that, if the configuration fails, I have a plugin loaded and cannot unload it (.NET assemblies cannot be unloaded!).

So it would still be nice to pass some Properties interface to the plugin factory (sort of like the TransportInfo interface discussed in another thread).

Karl

[mes]

Hi,

An application can manually install a plugin using the PluginManager interface, in which case any sort of configuration is possible since the application is interacting directly with the plugin implementation. Otherwise, the expectation is that a dynamically-loaded plugin can derive its configuration information from the trailing arguments in the plugin property, or from the communicator's property set.

Also, failure to initialize a plugin is considered a fatal error. The plugin should raise a PluginInitializationException, which causes communicator initialization to fail. The application should not continue in this case.

- Mark

[kwaclaw]

An application can manually install a plugin using the PluginManager interface, in which case any sort of configuration is possible since the application is interacting directly with the plugin implementation. Otherwise, the expectation is that a dynamically-loaded plugin can derive its configuration information from the trailing arguments in the plugin property, or from the communicator's property set.

The trailing arguments won't help, as at that point the assembly is already loaded, but PluginManager.addPlugin(string name, Ice.Plugin pi); will work, as plugin creation is under application control.

Thanks,

karl

[mes]

The trailing arguments won't help, as at that point the assembly is already loaded

Sorry, I don't understand why this is a problem. Can you elaborate?

- Mark

[kwaclaw]

Sorry, I don't understand why this is a problem. Can you elaborate?

In order to execute code for the plugin factory, the assembly must be loaded first, of course. If property validation happens then, it is too late, as a .NET assembly cannot be individually unloaded, unless it runs in its own AppDomain.

However, if I can perform property validation before the assembly is even loaded then I can avoid this. This comes at the cost of having the application do the validation.

Another option could be to use a separate - small - configuration check assembly which then loads the actual plugin assembly, if validation succeeds.

Karl

[mes]

What is the problem with having the assembly loaded? Are you hoping that the application would be able to recover from a property validation failure?

- Mark

[kwaclaw]

What is the problem with having the assembly loaded? Are you hoping that the application would be able to recover from a property validation failure?

Yes, if the loaded properties are not OK, one might want to load
from an alternate source, or come up with workable defaults
depending on application circumstances.

Karl

[kwaclaw]

Hi,
I think you can reasonably expect that ZeroC will eventually implement an SSL plugin for C#, and we will call it IceSSL. Therefore it's not a good idea for a third-party implementation to use this name. Using your own property prefix, you will not have to worry about the Ice run time's property validation, and your plugin can validate its configuration however it wishes.

I am currently using the namespace "IceSsl" in my plugin, however, I assume this is the one you will want to use. To avoid name clashes, I would like to use "Ice.Ssl" instead, since this would not interfere with your flat namespace hierarchy.

Karl