The HAL management console provides the UI to configure almost any subsystem in WildFly. However for subsystems provided by 3rd party projects like PicketLink, Teiid or Keycloak there’s no way to configure the management resources. This is where the HAL extensions come into play. They provide an easy way to extend the console and provide a frontend to configure the related subsystem. This blog post will walk through the process from creating an extension to including it in the HAL release stream.
Before we start let me give you some technical background. The HAL management console is a GWT web application. It uses a maven build and depends mainly on GIN for dependency injection and GWTP for MVP. Extensions need to use the same stack and must create a maven artifact which is used by the HAL release stream at compile time. As a result the final management console is produced. This means that the final console might contain many extensions. However the extensions will only show up if the relevant subsystem is part of WildFly. Furthermore since the console uses code splitting the extension’s bits & pieces will only be loaded on demand.
As of today extensions need to be developed against HAL 2.8.0 or greater. This in turn requires WildFly 10.x as target platform. To get started quickly we provide a maven archetype. The archetype creates an extension with a presenter / view tuple to edit the top level attributes of a given subsystem.
Besides the regular maven coordinates like
artifactId et al the archetypes uses the following parameters:
extensionName: The name / title of the extension as it appears in the UI. Should be a human friendly term which can contains spaces.
gwtModuleThe name of the GWT module w/o the
.gwt.xmlsuffix. Must not contain whitespace.
subsystem: The name of the subsystem. The extension will only show up in the UI if the subsystem is configured in standalone mode or is part of the selected profile in domain mode.
nameToken: An unique name token used to identify the extension’s page in the UI. Should be an all lowercase string separated with dashes. Defaults to the subsystem name. See the GWTP documentation for more infos about place management.
The archetype is deployed to the JBoss Maven Repository. In order to use it, make sure to specify the catalog flag
Let’s say we want to develop an extension for the subsystem
request-controller. This subsystem is used for request limiting and graceful shutdown and is currently not covered in the HAL management console. Open a shell and execute
1 2 3 4
After providing all required parameters you should end up with a new maven project which consists of two sub modules:
gui: Contains the GWT code for the extension
app: Provides a GWT module to run and test the extension
Before we dive into the details, here’s a preview of what the extension is going to look like in the navigation, read-only and edit mode:
The development of the extension happens in the
gui module. The archetype creates all necessary building blocks:
- a presenter / view tuple
- the GIN / GWTP mixins
- i18n helper classes
Presenter / View Tuple
The GWTP presenter includes the proxy interface which carries the
@SubsystemExtension annotation. This annotation marks the enclosing presenter as an extension. The view interface defines a method to update the view with the subsystem data. Finally there are two methods to load and save the subsystem attributes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
The view creates a form based on the subsystem metadata. When the user clicks save, control is delegated to the presenter which executes the relevant DMR operations to store the updated attributes in the management model.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55
GIN / GWTP Mixins
These mixins are needed to extend the dependency injection scope and wire up the presenter / view tuples. A mixin is declared both as a binding and model extension. The
@GinExtension value refers the GWT module descriptor used with the extension.
The injection points:
1 2 3 4
The actual binding:
1 2 3 4 5 6 7 8 9 10 11
Finally the archetype creates some helper classes to deal with i18n constants and messages. It provides both access to HAL’s constants and messages and to the resources defined by the extension:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
To launch the extension, switch to the
app directory and execute one of the following:
mvn gwt:runfor GWT SuperDevMode
mvn gwt:run|debug -Dgwt.superDevMode=falseto use the old DevMode. Please note that you’ll need Firefox <= 26 and the GWT plugin to use DevMode.
You’ll need a running WildFly instance which is configured to allow access from http://localhost:8888. Use one of the following CLI commands to configure the management endpoint:
/host=master/core-service=management/management-interface=http-interface:list-add(name=allowed-origins,value=http://localhost:8888) reload --host=master
Please note that the extension will only show up in the UI if the subsystem is configured in standalone mode or is part of the selected profile in domain mode.
The HAL release stream is a maven build which combines different extensions at compile time and generates a final management console. You can clone its repository to test the build with your extension. Please contact us if you want to include your extension into the release stream.
It’s your turn
Now if you want to write your own extension, great - go ahead! If you have any questions or comments, please do not hesitate to contact us.