The biggest news in the SwanLoom project (to be renamed to WindRide) is that the migration rules are now externalized. But:

• What are they externalized to?
• How powerful the rules are?
• How to add it to the application and use it?
• When will we colonize Mars?

Answers to these questions can be found in this introductory video.

More videos here.

Sorry for my accent, I am blushing when I hear it. Still - enjoy :-)

Here's the text, for SEO purposes.

Hello. I'm Ondra Žižka, and I will introduce the latest feature of WindRide -

which is a tool for migrating the configuration of JBoss Enterprise Application Platform (or EAP)

from version 5 to version 6. (Support for other servers will be added later.)

 

The latest feature is that the migration logic is externalized into XML files.

Let's see how it works.

 

The big picture is:

 

1. Query the source server for collection of information,

2. Iterate over these collections,

3. Take the actions based on what is found.

 

Now let's see how to define that.

 

The XML file contains a definition of so-called migrator, which is a logical group of actions covering certain configuration area, for example, datasources.

 

Migrator has a name which is then used by the program to refer to it.

 

It contains JAXB beans declarations, queries, and actions.

 

JAXB beans declarations tell the program what classes will be used for unmarshalling the configuration.

Since all of the application servers store their configuration mostly in XML files, JAXB is a natural choice.

 

Then comes an example of a query; in this case, it's an XML query. There are more types, for example, properties file query.

Different types target different ways of how configuration is stored in the source server.

More details about queries can be found in the project's documentation.

 

All queries have an ID, by which their result is referred in the actions.

Subject label is used in user interface, and for the HTML reports and error messages.

Other query attributes are specific for the particular query type.

 

Actions define the actual steps taken during migration.

Again, there are different types, specified by the `type` attribute.

Few types are built in, like CLI command action, XSLT transform action, file copy, and so on.

Custom actions may be implemented either in Java or Groovy. See the documentation for a how to.

 

A reference to the action may be stored in a variable.

If you are familiar with Ant, you can think of the action as an Ant task.

 

Typically, you need to migrate multiple configuration items.

These items are stored in collections returned by the aforementioned queries.

To iterate over the collections, the <forEach> element is used.

You refer the query, and declare the name of variable to store the item for each iteration step.

 

Inside a loop, you may declare another loop, or an action.

This way, in cobination with queries, you have quite powerful tools at hand.

But that's not all.

 

As you probably noticed, there are expressions inside the values.

The syntax used is Java Expression Language 2.0.

The values available for the expression language are documented, but generally, you can use:

 

* application's configuration

* application's arguments

* queries' results

* Any parent in the nested constructs (like <forEach> and <action>)

 

The <filter> element is a condition in a form of a Groovy expression

which controls whether given construct will be processed for the current iteration.

The same variables are available for the script as for the expressions.

 

An action nested in another action creates a dependency of the parent action.

The inner action be performed prior to the parent action,

and if it fails, parent action also fails.

 

Lastly, the warning element attaches a warning to an action.

Each action may have a list of text messages, which are presented to the users

when their manual intervention is needed.

Typically, in these cases:

 

* Migration of certain configration item is not supported (yet)

* Migration is not possible (for example, there's no equivalent in the target server)

* Certain discrepancy or inconsistency was found in the source server configuration.

 

So these are the externalized rules in a nutshell.

And as you can see, the combination of instruments gives you quite powerful tool.

 

Please refer to the project's documentation to find out

about all the implemented JAXB beans, queries, actions, and also how to implement your own,

which will be also covered by the upcoming videos.

 

See you soon!