{section}
{column}
h1. Introduction
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, ...
* Additional internal component to add new features to Petals ESB, divided in two categories:
** *pre-extension*, must be loaded before internal components. A such additional internal component can be required by a mutable implementation of a required component (ex: the embedded registry overlay avoid to start an external registry overlay in a standalone topology)
** *post-extension* that is loaded after internal components. A such additional internal component is not required and not used by other internal components.
{column}
{column:width=35%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}
h1. The mechanisms
h2. Mechanism starting a Petals ESB node
When starting a Petals ESB node, the Fractal composite '*{{Petals}}*' is initialized and started. It is composed of following Fractal components or composites:
* {{ConfigurationServiceImpl}}, that manages the configuration of the Petals ESB node,
* {{PreExtensionsManager}}, that manages the pre-extensions to load before all internal components
* {{PetalsCompositeControllerImpl}}, that manages the startup of other Fractal components according to the current configuration.
{{PetalsCompositeControllerImpl}} starts, in order:
# internal components
# the extensions that must be loaded last.
The Fractal composition is controlled by the Fractal component 'PetalsCompositeControllerImpl'.
h2. Mechanism for pre-extensions
When Petals ESB starts, the classloader is scanned by the pre-extension manager ({{PreExtensionManagerImpl}}, a component of the composite {{PreExtensionsManager}}) to search all pre-extensions. When one is found, it is instantiated and started. A pre-extension is found when a Java class implementing the interface {{org.ow2.petals.microkernel.api.extension.PetalsPreExtensionController}} is found.
When a {{PetalsPreExtensionController}} is found, the extension manager ask the extension to create its own Fractal composite/component, bounds it and starts it.
All pre-extensions are unregistered, stopped and freed when the {{PreExtensionManagerImpl}} is stopped.
h2. Mechanism for mutable implementation
When {{PetalsCompositeControllerImpl}} starts, for each internal component providing mutable implementation, the classloader is scanned to search the mutable implementation. When one is found, it is instantiated, bound with other internal components and started.
A mutable implementation of an internal component is found when a Java class implementing the interface of the internal component is found.
h2. Mechanism for post-extensions
When Petals ESB starts, the classloader is scanned by the post-extension manager ({{PostExtensionManagerImpl}}) to search all post-extensions. When one is found, it is instantiated and started. A post-extension is found when a Java class implementing the interface {{org.ow2.petals.microkernel.api.extension.PetalsPostExtensionController}} is found.
When a {{PetalsPostExtensionController}} 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 with standard ways and uninstall or undeploy with your extension.
All post-extensions are unregistered, stopped and freed when the {{PostExtensionManagerImpl}} is stopped.
{column}
h1. Introduction
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, ...
* Additional internal component to add new features to Petals ESB, divided in two categories:
** *pre-extension*, must be loaded before internal components. A such additional internal component can be required by a mutable implementation of a required component (ex: the embedded registry overlay avoid to start an external registry overlay in a standalone topology)
** *post-extension* that is loaded after internal components. A such additional internal component is not required and not used by other internal components.
{column}
{column:width=35%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}
h1. The mechanisms
h2. Mechanism starting a Petals ESB node
When starting a Petals ESB node, the Fractal composite '*{{Petals}}*' is initialized and started. It is composed of following Fractal components or composites:
* {{ConfigurationServiceImpl}}, that manages the configuration of the Petals ESB node,
* {{PreExtensionsManager}}, that manages the pre-extensions to load before all internal components
* {{PetalsCompositeControllerImpl}}, that manages the startup of other Fractal components according to the current configuration.
{{PetalsCompositeControllerImpl}} starts, in order:
# internal components
# the extensions that must be loaded last.
The Fractal composition is controlled by the Fractal component 'PetalsCompositeControllerImpl'.
h2. Mechanism for pre-extensions
When Petals ESB starts, the classloader is scanned by the pre-extension manager ({{PreExtensionManagerImpl}}, a component of the composite {{PreExtensionsManager}}) to search all pre-extensions. When one is found, it is instantiated and started. A pre-extension is found when a Java class implementing the interface {{org.ow2.petals.microkernel.api.extension.PetalsPreExtensionController}} is found.
When a {{PetalsPreExtensionController}} is found, the extension manager ask the extension to create its own Fractal composite/component, bounds it and starts it.
All pre-extensions are unregistered, stopped and freed when the {{PreExtensionManagerImpl}} is stopped.
h2. Mechanism for mutable implementation
When {{PetalsCompositeControllerImpl}} starts, for each internal component providing mutable implementation, the classloader is scanned to search the mutable implementation. When one is found, it is instantiated, bound with other internal components and started.
A mutable implementation of an internal component is found when a Java class implementing the interface of the internal component is found.
h2. Mechanism for post-extensions
When Petals ESB starts, the classloader is scanned by the post-extension manager ({{PostExtensionManagerImpl}}) to search all post-extensions. When one is found, it is instantiated and started. A post-extension is found when a Java class implementing the interface {{org.ow2.petals.microkernel.api.extension.PetalsPostExtensionController}} is found.
When a {{PetalsPostExtensionController}} 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 with standard ways and uninstall or undeploy with your extension.
All post-extensions are unregistered, stopped and freed when the {{PostExtensionManagerImpl}} is stopped.