Petals ESB Container

Migrate from Fractal Spoon to the new Fractal Juliac Compiler version 2.6

Details

  • Description:
    Hide

    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:

    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!
    Show
    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: 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!
  • Environment:
    -

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:32:08 +0100

Everything is almost completely working.

The code compiles

  • Fraclet annotated classes
  • use latest version of fraclet annotations (3.3)
  • their description is compiled to .fractal and java (but not replacing the class itself)
  • are instantiable from Java directly
  • Composite .fractal definition
  • are compiled to .java and refer to the .fractal compiled files from the fraclet java classes
  • are instantiable from Java directly

We also rely on fractal-jmx that contains one primitive component defined using the fractal java interfaces (and not the fraclet annotations).
This was a problem at first but we found a solution: http://mail.ow2.org/wws/arc/fractal/2015-03/msg00001.html

Show
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:32:08 +0100 Everything is almost completely working. The code compiles
  • Fraclet annotated classes
  • use latest version of fraclet annotations (3.3)
  • their description is compiled to .fractal and java (but not replacing the class itself)
  • are instantiable from Java directly
  • Composite .fractal definition
  • are compiled to .java and refer to the .fractal compiled files from the fraclet java classes
  • are instantiable from Java directly
We also rely on fractal-jmx that contains one primitive component defined using the fractal java interfaces (and not the fraclet annotations). This was a problem at first but we found a solution: http://mail.ow2.org/wws/arc/fractal/2015-03/msg00001.html
Hide
Permalink
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:32:31 +0100

Problems 1:

Because the Java code relies on the generated classes, and to generate classes, juliac needs to access the compiled code, when a fraclet component is defined in a project and is also used directly in it (which is the case for all our projects), it is not possible to directly call the generated classes.
Hence, it was needed to reimplement the method to create components (that are in FractalHelper) to either:

  • take the name of a composite as a parameter to instantiate its class through reflection.
  • take the class of a primitive fraclet component to instantiate its class through reflection.

This is always better than what we had before, but it is too bad we can't just refer to the generated classes for now.
This would implies separating the definition of the components from their instantiation, which implies a lot of change to the architecture of petals (at least from the module point of view).

Show
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:32:31 +0100 Problems 1: Because the Java code relies on the generated classes, and to generate classes, juliac needs to access the compiled code, when a fraclet component is defined in a project and is also used directly in it (which is the case for all our projects), it is not possible to directly call the generated classes. Hence, it was needed to reimplement the method to create components (that are in FractalHelper) to either:
  • take the name of a composite as a parameter to instantiate its class through reflection.
  • take the class of a primitive fraclet component to instantiate its class through reflection.
This is always better than what we had before, but it is too bad we can't just refer to the generated classes for now. This would implies separating the definition of the components from their instantiation, which implies a lot of change to the architecture of petals (at least from the module point of view).
Hide
Permalink
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:37:57 +0100

Problem 2:

There is a misunderstanding on the meaning of starting and stopping a component:

We consider that starting and stopping is about completely stopping a component, but it seems that the idea behind these control operations was to be able to simply stop the business aspect of a component, for example when modifying its structure.

So in the current and default implementation of fractal/juliac/julia, it is assumed that a component will be stopped before removing subcomponents from it.

This is problematic because we do use this functionality when petals components are uninstalled for example.

There is 2 possible solutions:

The second one is easier, but is less clean and requires a bit of work.
In a way it will also give us more control on all the classes that we rely on… (the pre-generated pre-mixed juliac generated code).

To be continued…

Show
Victor NOËL added a comment - Tue, 3 Mar 2015 - 10:37:57 +0100 Problem 2: There is a misunderstanding on the meaning of starting and stopping a component: We consider that starting and stopping is about completely stopping a component, but it seems that the idea behind these control operations was to be able to simply stop the business aspect of a component, for example when modifying its structure. So in the current and default implementation of fractal/juliac/julia, it is assumed that a component will be stopped before removing subcomponents from it. This is problematic because we do use this functionality when petals components are uninstalled for example. There is 2 possible solutions: The second one is easier, but is less clean and requires a bit of work. In a way it will also give us more control on all the classes that we rely on… (the pre-generated pre-mixed juliac generated code). To be continued…
Hide
Permalink
Victor NOËL added a comment - Mon, 9 Mar 2015 - 11:50:48 +0100

To solve the previous problem about stopping and starting components, I chose to override the implementation used for that part.
It means generating base "pre-mixed" classes extended by the generated code from our component, instead of using those provided by juliac as a default (it is called pre-mixed because the code generated from the component definition is coming from mixins that implements the operative logic of the component structure).
This "pre-mixed" code is located in petals-microkernel-api as it is needed by all the project using this dependency and is related to the logic used to instantiate components in FractalHelper located in the same project.

Two things were disabled: checking the state of a component when removing a subcomponent, and checking the state of a component when removing a binding from it (the latter was needed because subcomponents must be unbound before being removed).

Show
Victor NOËL added a comment - Mon, 9 Mar 2015 - 11:50:48 +0100 To solve the previous problem about stopping and starting components, I chose to override the implementation used for that part. It means generating base "pre-mixed" classes extended by the generated code from our component, instead of using those provided by juliac as a default (it is called pre-mixed because the code generated from the component definition is coming from mixins that implements the operative logic of the component structure). This "pre-mixed" code is located in petals-microkernel-api as it is needed by all the project using this dependency and is related to the logic used to instantiate components in FractalHelper located in the same project. Two things were disabled: checking the state of a component when removing a subcomponent, and checking the state of a component when removing a binding from it (the latter was needed because subcomponents must be unbound before being removed).
Hide
Permalink
Victor NOËL added a comment - Thu, 12 Mar 2015 - 09:41:06 +0100

About the fix version: I told Juliac team (see http://mail.ow2.org/wws/arc/fractal/2015-03/msg00051.html) that we will try to release the migration to juliac with version 4.3 if possible, so I guess he will try to release a stable version of juliac for that time

Victor

Show
Victor NOËL added a comment - Thu, 12 Mar 2015 - 09:41:06 +0100 About the fix version: I told Juliac team (see http://mail.ow2.org/wws/arc/fractal/2015-03/msg00051.html) that we will try to release the migration to juliac with version 4.3 if possible, so I guess he will try to release a stable version of juliac for that time Victor
Hide
Permalink
Victor NOËL added a comment - Fri, 27 Mar 2015 - 11:58:56 +0100

I think we can consider this as fixed.

Show
Victor NOËL added a comment - Fri, 27 Mar 2015 - 11:58:56 +0100 I think we can consider this as fixed.

People

Dates

  • Created:
    Thu, 12 Feb 2015 - 11:39:50 +0100
    Updated:
    Wed, 15 Jul 2015 - 09:32:01 +0200
    Resolved:
    Fri, 27 Mar 2015 - 11:58:56 +0100
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.