E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (5)
View Page History
...
{section} 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, ...
* 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. A such additional internal component is not required and not used by other internal components. 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.
** *post-extension* that is loaded after internal components. A such additional internal component is not required and not used by other internal components.
{column}
...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:
* {{ConfigurationServiceImpl}}, that manages the configuration of the Petals ESB node,
* {{PetalsCompositeControllerImpl}}, that manages the startup of other Fractal components according to the current configuration.
{{PetalsCompositeControllerImpl}} starts, in order:
# the extensions that must be loaded first,
# internal components
# the extensions that must be loaded last.
The Fractal composition is controlled by the Fractal component 'PetalsCompositeControllerImpl'
When starting a Petals ESB node, the Fractal composite '*{{Petals}}*' is initialized and started. It is composed of following Fractal components:
* {{ConfigurationServiceImpl}}, that manages the configuration of the Petals ESB node,
* {{PetalsCompositeControllerImpl}}, that manages the startup of other Fractal components according to the current configuration.
{{PetalsCompositeControllerImpl}} starts, in order:
# the extensions that must be loaded first,
# internal components
# the extensions that must be loaded last.
The Fractal composition is controlled by the Fractal component 'PetalsCompositeControllerImpl'
h2. Mechanism for additional internal component
...h2. Mechanism for mutable implementation
This nature of extension will be supported soon.
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.
A mutable implementation of an internal component is found when a Java class implementing the interface of the internal component.