Petals ESB implements a plug-in mechanism to be able to extend it with new features. Some optional features of Petals ESB are developed as extensions: [Petals Autoloader|Petals ESB "Autoloader"], Petals Artifact Repository, Petals WS-API.

Two extension natures are supported:
* Mutable implementation of required internal component: the implementation of an internal required component can be changed to be adapted to the use cases, for example: remote transporter, in-memory repository, ...

h2. Mechanism for additional internal component

When Petals ESB starts, the classloader is scanned by the extension manager to search all extensions. When one is found, it is instantiated and started. An extension is found when a Java class implementing the interface {{org.ow2.petals.microkernel.api.extension.PetalsExtensionController}} is found.

When a {{PetalsExtensionController}} is found, the extension manager ask the extension to create its own Fractal composite/component. Next if the extension is a typed extension (see below), the extension manager registers the new extension to the its associated extension manager.

An extension can be typed to have more interaction with other components. Only one sub-type is supported nowadays:
* {{InstallationExtension}}: a such extension interacts with installation and deployment subcomponent, so you install or deploy wiith standard ways and uninstall or undeploy with your extension.

All extensions are unregistered, stopped and freed when the {{ExtensionManager}} is stopped.


h2. Mechanism for mutable implementation

This nature of extension will be supported soon.