Application extension registry
WAS has enabled the Eclipse extension framework for applications to use. Applications are extensible when they contain a defined extension point and provide the extension processing code for the extensible area of the application.
An application can be plugged in to another extensible application by defining an extension that adheres to what the target extension point requires. The extension point can find the newly added extension dynamically and the new function is seamlessly integrated in the existing application. It works on a cross J2EE module basis. The application extension registry uses the Eclipse plug-in descriptor format and APIs as the standard extensibility mechanism for WebSphere applications. Developers that build WebSphere application modules can use WAS extensions to implement their functionality to an extensible application, which defines an extension point. This is done through the application extension registry mechanism.
The architecture of extensible J2EE applications follow a modular design to add new functional modules or to replace an existing module, particularly by those outside of its core development team. Each module is a pluggable unit, or plug-in that is either deployed into the portal or removed from the J2EE application using a deployment tool that is based upon standard J2EE and portal Web module deployment tooling. A plug-in module describes where it is extensible and what capability it provides to other plug-ins in the plugin.xml file. The plugin.xml manifest file can be created with a simple text editor or in Eclipse's Plug-in Development Environment (PDE), which provides a simplified view of the same underlying XML data.
WAS implementations to the Eclipse model
Some minor differences exist in the WAS implementation of this architecture because of platforms, specifically, Eclipse Workbench or J2EE. The highlights of the WAS implementation include:
- Implementing all of the extension registry-related interfaces from Eclipse 3.1.
- The identical plugin.xml syntax, however, some attributes are not used, for example, <runtime>.
- The discovery and addition of plug-ins to the registry, when the containing J2EE module starts, and plug-ins are dismissed and removed from the registry when the containing J2EE module stops.
- Access to an IExtensionRegistry object is through the JNDI, instead of by using the Platform.getExtensionRegistry method in the Eclipse Workbench.
- Filtering capability is available by providing a filter implementation and using a named registry instance that finds and invokes the filter as necessary. See the developer API documentation for the IExtensionRegistryFilter interface for more details.
Available Eclipse 3.1 interfaces
The following Eclipse 3.1 interfaces are available on WAS:
- Extension registry API
- Extension point API
- Extension API
- Configuration element API
- Registry change listener API
- Registry change event API
- Extension delta API
- Status API
The following interfaces are recognized and processed the same as in Eclipse:
Related concepts
Application extension registry filtering
Related tasks
Define an extension for the registry filter
Related Reference
Web applications: Resources for learning
plugin.xml file
API documentation