[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.equinox] Re: How are dependent plugins handled with unloading/reloading?
In the current context, we are discussing dynamic plugins and their registry.

I'd like to point out that in the OSGi we found the registry model also -very- applicable for many other patterns. In our case, devices that are discovered in the outside world are also registered in the service registry. We discovered the "white board approach" which is the model where you just register an object in the register in the hope somebody picks it up and can do something useful with it. This approach has been VERY succesful so maybe we can keep in mind that a general registry has many advantages.

Another thing we learned in OSGi is that tracking those plugins (services) can be painful. We therefore included a ServiceTracker utility in R2 that makes handling this dynamic aspect quite easy.

In this thread there is a discussion of locking a service in memory. We discussed this extensively in OSGi and decided against that because it is extremely deadlock prone. We accept the fact that there is a failure mode in a short window where a service can become stale. With Java and the exception model I think this is acceptable (it is not like C where there would be a core dump).

As a last point, I think we should realize that the dynamic plugins are VERY different beasts than static. I think it is important to fully support the current model in Equinox but offer a new, more dynamic, model. One will have to rewrite (part of) its plugin when supporting or taking advantage of the dynamics.

Kind regards,

	Peter Kriens

Mel Martinez wrote:

Kevin wrote:

Hi am curious, if a plugin is unloaded or reloaded at runtime, how are all
dependent plugins treated? Do they all get unloaded by the engine, then
reloaded and reconnected when the requested reload operation is completed?
Or do they just sit idle, hoping that events or what have you do not come to
them that require their code to work with a plugin that may be in the middle
of a reload (or might have been unloaded completely)?


It kind of depends on the nature of the dependency. If the dependency is based on class visibility, like so:

  SomePlugin p = (SomePlugin)Platform.getPlugin("some.plugin.id");
  p.someMethod();

Then if the SomePlugin class gets unloaded and reloaded, the above code will no longer be valid and would also have to be reloaded. If the dependency is indirect and only through platform API's:

  Plugin p = Platform.getPlugin("some.plugin.id");
  p.setDebugging(true);

Then this code MAY be decoupled, so long a it doesn't try to statefully retain the reference 'p'. I.E., 'p' should be a local (method) variable and never stored in a class or instance variable. A way of working around that limitation is to use the Observer pattern to notify dependents via events that SomePlugin is about to be unloaded. An event listener callback method could then be used to release (nullify) any instance or class references to the plugin (or any class provided by the plugin). Another alternative is to write your code ready and willing to deal with ClassDefNotFound and NullPointerExceptions. :-) Not a bad idea in general, really.

My initial assumption is that somehow the engine must "pause" or completely
unload all dependent plugins as well. My concern here if it is done in this
manner is the time to reload a single plugin could be noticeable. However, I
guess the question to be asked is, how often is any plugin reloaded at
runtime anyway? I can't think of any application, other than perhaps an
application during development/debug cycles, that would require plugins to
be reloaded at runtime, with the exception of an application that may check
for updates via a menu item click or button click, and if found, would
auto-reload the new version of the plugin. In most apps, like Photoshop, 3D
applications, even Eclipse, the most common place to reload a plugin is
actually at the start of the app, where it may load the plugin the first
time if a new version exists. I really don't see a strong need for reloading
during an application execution.


My group has a very very strong interest in the ability to add/remove functionality during runtime with varying degrees of integration. I'm not sure I want to or should get into the specifics of our particular use cases. However, consider the analogy to broadly-purposed application platforms such as a web-browser, which can run a variety of independent thin-client applications (html pages, javascript, applets, flash) that are loaded/unloaded/reloaded independent of each other, yet still gain additional utility through consistency of the platform and at least a thin layer of integration. Perhaps a better example might be Lotus' Notes, which provides a vehicle for the deployment of a great variety of much richer, full-featured (thick) applications that can be added/removed from the user's environment yet still have a high level of consistency and integration.

Mel