Petals ESB Container

For now we use Fractal in the following way:

• Fractal Components implementations are annotated with an old annotation library called fraclet 2.0.2.
• http://fractal.ow2.org/fraclet/migration.html#annotation
• These implementation are transformed to fractaladl definitions using an old spoon maven plugin and spoonlet, the implementation of the transformation.
• http://alchim.sourceforge.net/spoon-maven-plugin/
• https://github.com/davidB/spoon-maven-plugin/
• Fractal composite components are described using the fractal adl, and refer to implementation's fractaladl definitions (e.g.: <component definition="org.ow2.petals.extension.autoloader.AutoLoaderServiceImpl" name="AutoLoaderServiceImpl"/>).
• The implementations are also modified at the bytecode level to include needed methods implementation for fractal (binding methods and so on).
• Components are instantiated at runtime by referring to their fractaladl definition, which then instantiate the implementations when needed (e.g.: FractalHelper.createNewComponent(AUTOLOADER_COMPOSITE) with AUTOLOADER_COMPOSITE a String) and also generate classes at runtime.

The problem with that are:

• The bytecode manipulation makes debugging painful because the classes content is changed and recompiled with an old eclipse jdt.
• The runtime instantiation using String is not the best in term of type safety.
• The runtime instantiation relies on runtime bytecode manipulation and interface creation, which is not the most efficient.
• The runtime instantiation prevent the use of tools like jacoco for verifying test coverage.
• The implementation used is old and maybe some bugfixes were fixed now.
• The spoon version we need and the fraclet are not maintained anymore

With Juliac, we would use Fractal like this:

• Fractal Components implementations are annotated with the new annotation library called fraclet 3.3.
• http://fractal.ow2.org/fraclet/migration.html#annotation
• Fractal composite components are described using the fractal adl, and refer to implementation's fractaladl definitions (e.g.: <component definition="org.ow2.petals.extension.autoloader.AutoLoaderServiceImpl" name="AutoLoaderServiceImpl"/>).
• Juliac will generate the classes needed by component that were previously generated at runtime
• Juliac will generate the classes for the implementations, but without modifying them, only generating new classes that refer to the implementation
• Juliac will generate classes for the composites.
• Composites will be instantiable from their generated class (Petals.newFcInstance())
• Implementation, if needed for example for extensions, will be instantiable from the generated class (that have a name that contains a unique but stable id, see http://mail.ow2.org/wws/arc/fractal/2015-02/msg00030.html to understand why)

Advantages will be:

• no runtime bytecode manipulation
• no offline bytecode manipulation
• nice debugging
• cleaner code
• potential bug fixes
• maintained tool (spoon and fraclet were not really maintained)

Discussions for this to be possible (because it doesn't work with the current stable version of juliac) are initiated:

• http://mail.ow2.org/wws/arc/fractal/2015-01/msg00000.html
• Now it works good (using the 2.6-SNAPSHOT version of juliac): http://mail.ow2.org/wws/arc/fractal/2015-02/msg00024.html
• We are waiting for a release then

Work to be done:

• migrate all the fractal implementations to the new fraclet annotation (I did it already locally for the microkernel)
• change the way components are instantiated: normally we just need to replace calls to fractal.adl.Factory with calls to the generated class... to be investigated!