| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| <title>The Equinox Project - Deactivating plugins</title> |
| <link rel="stylesheet" title="default" href="http://eclipse.org/default_style.css" type="text/css"> |
| </head> |
| <body> |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=left width="60%"> |
| <p><font class=indextop> equinox</font><br> |
| <font class=indexsub> dynamic plugins > deactivating plugins</font> </p> |
| </td> |
| <td WIDTH="40%"> </td> |
| </tr> |
| </table> |
| <p> Deactivating plugins is the act of moving an activated plugin to deactivated |
| state. This does not remove it from the registry but runs the plugin's shutdown |
| lifecycle and returns the plugin to the same state as it was before it was activated |
| (i.e., when the platform started). All extensions and extension-points remain |
| in place in the registry. </p> |
| <p /> There are two reasons for deactivating a plugin: |
| <ol> |
| <li> regain some space by removing any structures required by the plugin and |
| recovering the space required for its classes. </li> |
| <li> as a prelude to removing the plugin from the registry, also known as disablement (see <a href="glossary.html">glossary</a>).</li> |
| </ol> |
| <p> Note that deactivating a plugin A which is required by plugin B does <b>not</b> |
| imply the B <b>must</b> be deactivated -- just as activating B does not imply |
| that A is activated.</p> |
| <p></p> |
| <p>Deactivating a plugin does not itself require additional lifecycle events. |
| However, in general, other plugins have references to newly deactivated classes/objects |
| and the plugin being deactivated may not cleaned up after themselves. As a result, |
| some notification will be required to tell plugins to clean up their structures. |
| </p> |
| <p>A plugin that is being shutdown should clean up its internals to limit the |
| number of external references it might have. However, it is often other plugins |
| have references to instances of the deactivated plugin's classes (e.g., the |
| resources plugin references supplied builder classes). This prevents those classes |
| and thus the plugin's classloader from being garbage collected. </p> |
| <p> One simple approach that can be implemented in the Eclipse runtime infrastructure |
| is to manage instances created via createExecutableExtension(). This is the |
| method used to create instances of classes provided via extensions to extension-points. |
| Since this code path goes through runtime code, the runtime could track instances |
| created and at report on plugins which retain references after a plugin is deactivated. |
| For more details, see <a href="classloadersAndInstances.html"> managing classloaders |
| and instances</a>. </p> |
| <p>Another approach simply broadcasts the deactivation notice and plugins hosting |
| extensions from the plugin being deactivated are responsible for the cleanup. |
| </p> |
| <p>Pragmatically, both approaches should be supported.</p> |
| |
| <table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" > |
| <tr> |
| <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font color="#FFFFFF"> |
| Notification mechanism</font></b></td> |
| </tr> |
| </table> |
| The notification mechanism will only broadcast "Plugins events". As a reminder the events are "activated" |
| and "deactivated".</br> |
| The notified plugins will at least be: |
| <ul> |
| <li>all the plugins in the transitive closure of the deactivated plugin</li> |
| <li>plugins depeding on the deactivated plugin</li> |
| <li>plugins providing extensions to the deactivated plugin</li> |
| <li>plugins to which the deactivated plugin provide extensions</li> |
| </ul> |
| |
| </p> |
| |
| The infrastructure for the following notification mechanism is: |
| <ul> |
| - a PluginEvent class flagged with "actived" or "deactivated" as well as a collection of plugins;<br> |
| - a registration mechanism;<br> |
| - addition of a method in the Plugin class to receive the notification (the method will come from an interface);<br> |
| </ul> |
| |
| Is there a necessity to have a notification before and after the actual state change?<br> |
| Is there a necessity of registring to those events through extension points?<br> |
| What about letting the plugin decide wheter or not it wants to be deactivated on the deactivation of a prerequisite deactivation?<br> |
| |
| <p>See also:</p> |
| <ul> |
| <li><a href="usecases.html">usecases</a></li> |
| </ul> |
| <p> </p> |
| <p /> |
| </body> |
| </html> |
