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