|
|
|
|||||
|
Plugin configuration
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 |
|
|||||
|
Quote:
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 |
|
||||||
|
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 |
|
|||||
|
Quote:
Thanks, karl |
|
||||||
|
Quote:
- Mark |
|
|||||
|
Quote:
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 |
|
|||||
|
Quote:
from an alternate source, or come up with workable defaults depending on application circumstances. Karl |
|
|||||
|
Namespace to use?
Quote:
Karl |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Setting a default configuration file | eric.hill | Help Center | 14 | 07-03-2008 10:01 AM |
| Configuration problems with PHP | davidcr1983 | Help Center | 7 | 08-29-2006 06:25 PM |
| IcePack and Glacier2 configuration | xdm | Help Center | 4 | 06-01-2005 12:37 PM |
| how to write a plugin for ice use C++? | damingyipai | Help Center | 4 | 02-06-2005 08:16 PM |
| IceStorm example - configuration | Bruce | Help Center | 1 | 03-18-2004 12:57 PM |