- FAQ 94: What is a plug-in?
- FAQ 95: Do I use plugin or plug-in?
- FAQ 96: What is the plug-in manifest file (plugin.xml)?
- FAQ 97: How do I make my plug-in connect to other plug-ins?
- FAQ 98: What are extensions and extension points?
- FAQ 99: What is an extension point schema?
- FAQ 100: How do I find out more about a certain extension point?
- FAQ 101: When does a plug-in get started?
- FAQ 102: Where do plug-ins store their state?
- FAQ 103: How do I find out the install location of a plug-in?
- FAQ 104: What is the classpath of a plug-in?
- FAQ 105: How do I add a library to the classpath of a plug-in?
- FAQ 106: How can I share a JAR among various plug-ins?
- FAQ 107: How do I use the context class loader in Eclipse?
- FAQ 108: Why doesnt Eclipse play well with Xerces?
- FAQ 109: What is a plug-in fragment?
- FAQ 110: Can fragments be used to patch a plug-in?
- FAQ 111: What is a configuration?
- FAQ 112: How do I find out whether the Eclipse Platform is running?
- FAQ 113: Where does System.out and System.err output go?
- FAQ 114: How do I locate the owner plug-in from a given class?
- FAQ 115: How does OSGi and the new runtime affect me?
- FAQ 116: What is a dynamic plug-in?
- FAQ 117: How do I make my plug-in dynamic enabled?
- FAQ 118: How do I make my plug-in dynamic aware?
FAQ 117: How do I make my plug-in dynamic enabled?
Most of the effort required to make a plug-in dynamic enabled can be summed up as doing what you should be doing anyway as part of good programming practice. Most importantly, to be dynamic enabled, your plug-in has to properly clean up after itself in the Plugin shutdown method. You need to keep in mind the following checklist for your plug-in’s shutdown method.
If you have added listeners to notification services in other plug-ins, you need to remove them. This generally excludes any listeners on SWT controls created by your plug-in. When those controls are disposed of, your listeners are garbage collected anyway.
If you have allocated SWT resources, such as images, fonts, or colors, they need to be disposed of.
Any open file handles, sockets, or pipes must be closed.
Any metadata stored by other plug-ins that may contain references to your classes needs to be removed. For example, session properties stored on resources in the workspace need to be removed.
Other services that require explicit uninstall need to be cleaned up. For example, the runtime plug-in’s adapter manager requires you to unregister any adapter factories that you have manually registered.
If your plug-in has forked background threads or jobs, they must be canceled and joined to make sure that they finish before your plug-in shuts down.
Prior to Eclipse 3.0, the consequences of failing to clean up properly were not as apparent as plug-ins were shut down only when the VM was about to exit. In a potentially dynamic world, the consequence of not being tidy is that your plug-in cannot be dynamic enabled.
FAQ 116 What is a dynamic plug-in?
FAQ 118 How do I make my plug-in dynamic aware?