External Migrator Execution - OndraZizka/jboss-migration GitHub Wiki

This is a developer documentation. See Migrator Definition Rules for user reference.

1. XML descriptor from *.mig.xml is read into MigratorDescriptor.

2. Migrator class is created and instantiated. May be further extended by a Groovy class.

3. It's createActions() calls this to create actions:

   MigratorDefinitionProcessor(this).process( this.descriptor );

4. That call starts traversing the tree of the migrator descriptor, implemented by [[MigratorDefinitionProcessor|https://github.com/OndraZizka/jboss-migration/blob/master/src/main/java/org/jboss/loom/migrators/_ext/process/MigratorDefinitionProcessor.java]].

   Currently, the tree is not traversed trully as a tree, rather different types of children are processed grouped by type, in hard-coded order. That will improve later.

5. According to what is found, actions are created.

6. These actions are then performed during the [[performActions()|https://github.com/OndraZizka/jboss-migration/blob/master/src/main/java/org/jboss/loom/MigrationEngine.java#L303]] stage.

Currently, action handling is hard-coded and only creates the built-in actions.
Later, implementations of [[IActionDefHandler|https://github.com/OndraZizka/jboss-migration/blob/master/src/main/java/org/jboss/loom/migrators/_ext/process/MigratorDefinitionProcessor.java#L284]] interface will define new actions.

Contexts serve mainly to keep the variables to be used in EL and Groovy scripts (<filter>).

• Root
• ForEach
• Actions

The contexts are kept in a stack - ContextsStack. They are added and removed as the migrator definition is traversed.
The ContextsStack can keep anything implementing the ProcessingStackItem interface, which currently has only getVariable( String ) method.

Besides keeping the contexts, ContextsStack also implements the logic of retrieving the variables from the nearest context which has it - getVariable( String ), and also importantly, it propagates the structures created based on definition items through the stack up to anything what accepts it.
For example, a warning is EL-resolved and then offered to the stack, which traverses the contexts and offers it to each. Warning is accepted by actions, so the first action would consume it. If no context accepts it, an exception would occur, resulting in a migration error.

EL expression is evaluated by MigratorDefinitionProcessor's JuelCustomResolverEvaluator which is backed by ContextsStack which implements IVariablesProvider, and it's getVariable( String ) is used to resolve the variables.

TBD

Default base directory is

• Source server dir for queries.
• Target server dir for actions.
• Current workdir for the other.

Path variables available in EL:

• ${workdir}
• ${srcServer.dir}
• ${destServer.dir}
• ${migDefDir} - the directory containing the .mig.xml file.