Ship Your WildFly Additions via Galleon Feature Packs

We have some packages which contain the JBoss Modules for our subsystem and its dependency. These can be found under the galleon-pack/src/main/resources/modules/system/layers/base/ directory. The subsystem code is in the subsystem/ folder of the project, while the example subsystem dependency (which contains the CDI @Produces method mentioned) code is in the dependency/ folder of the project.

In addition we have some packages to deal with installing licenses for your added libraries. We won’t go into details of that here. See the the template README for more information.

We define a single feature group in galleon-pack/src/main/resources/feature_groups/template-subsystem.xml. The group contains the <feature spec="subsystem.template-subsystem"/> for our subsystem. The value of 'spec' used for these feature specifications is of the form

and it essentially configures the subsystem. In this case <subsystem name in the model> is 'template-subsystem', and this configuration results in a

when provisioning the server. Our subsystem is empty, if it had some attributes that need setting they would also be defined in the feature spec.

galleon-pack/src/main/resources/layers/standalone/template-layer/layer-spec.xml contains our single layer called ‘template-layer’. It adds dependencies on the following other constructs:

galleon-pack/wildfly-feature-pack-build.xml is used to provision new features (the template README explains how to install additions which have no configuration). It adds our extension module org.wildfly.extension.template-subsystem to the configuration. Galleon is smart enough to inspect this module’s dependencies and automatically add our org.wildfly.template-dependency module.

The file also sets up the feature packs we depend upon in order to provide the underlying server.

Finally we have the feature pack build in galleon-pack/pom.xml. It contains the wildfly-galleon-maven-plugin which creates the Galleon feature pack. Note that it uses the build-feature-pack goal which is needed to add a new subsystem along with the mentioned entry in wildfly-feature-pack-build.xml.

When building the galleon-pack/ module you can see what the feature pack contains in the galleon-pack/target/layout/org.wildfly.extras.galleon-feature-pack-template/template-galleon-pack/<version>/ directory to help you figure out what is missing if your feature pack does not work the way you expected.

Using the wildfly-galleon-maven-plugin Maven plugin isn’t really for end users, but it is very handy to be able to use it from within our project. For example, build/pom.xml provisions a server that we can use to verify that our feature pack works. Earlier in this post, we already played with the server in the build/target directory and deployed our example into that. Also, in our testsuite, testsuite/integration/subsystem/pom.xml provisions a server to run the Arquillian tests against.

In both cases we use the provision goal of the galleon-maven-plugin to provision a server. It lists the feature packs that our feature pack depends on (note that they are 'transitive') as well as the layers to install into our server. However, the layers used are slightly different in the two cases since we are doing two different things.

They both need our template-layer of course.

The build/ version is used to run our example from the example/ directory. As this uses a REST endpoint, we need the jaxrs layer to provide this functionality. Also, the wildfly:deploy goal we used to deploy the application uses the management interfaces, so it also needs the management layer.

The testsuite version, on the other hand, does not use REST for the test, so we just use the plain web-server layer (the jaxrs layer used in build/ depends on this web-server layer). Also, since Arquillian uses JMX to do the interactions with the server, we also need the jmx-remoting layer.

Galleon CLI is explained in more detail in the Galleon documentation. We will look at a few ideas for how to provision a WildFly server containing our plugin. There are probably other ways too, Galleon is very powerful! The two main ways to do this are to install the various parts manually, or to provision it from an xml file. Doing it manually is powerful, but there can be a lot of commands to remember. If you use an xml file to provision it, everything is contained in that file and you can run it again and again to provision servers using a simpler to remember command.

To use the Galleon CLI you need to download it. The following examples assume that you have added the bin/ folder of the distribution to your PATH (This is where the galleon.sh command comes from in the following examples).

We will look at how to provision the server via the two main mechanisms, then the Trying the provisioned server section below tells you how to run your application to check that our example subsystem got installed into the server and works as expected.

The example/ folder contains the sample application that you can deploy into the server. The steps to do this are the same whether you are using the example server from the build/ directory that we saw in the start of this post, or any of the Galleon CLI mechanisms.

The example itself is very simple, consisting of a single REST endpoint which is injected with a bean made available by the CDI @Produces method from the template subsystem dependency.

To run it, first start the server by running (the value of JBOSS_HOME is the root of the built server, which depends on which flavour of the provisioned server you are trying):

Then to deploy the application, in another terminal window in the checkout folder of the template project, run:

Then go to http://localhost:8080/example/greeting, which will output the message created by the CDI producer. As you refresh, the message will change.