Before WildFly 10, the patching implementation would support a single patch stream per installation. In other words, it would accept patches and updates targeting the identity installed and identified by the product name provided by org.jboss.as.version or org.jboss.as.product modules.

Following this concept, every identity must have its own patch and update stream, which means every EAP-based product and every layered product. The major problem with this approach is to fit official EAP patches and updates with the patches produced by other teams targeting other layers and components in the identity into a single patch stream. It would basically mean re-releasing official EAP and other layers' and components' patches with the adjusted for the specific identity the metadata. In addition to that, the release schedule of version updates (CPs) and the need to adjust to it in the patch production for products built on top of the EAP may make it even more complicated.

WildFly 10 removes most of the difficulties described above for layered products, add-ons and other components (such as deployments or, putting it simply, practically, any set of paths in the installation) in terms of patch production and application by supporting multiple independent patch and update streams. That means, that every layered product or an add-on, or component can have its own independent of the EAP patch and update stream and maintain its own patch history.

Changes in the CLI patching interface

The way the patches are applied hasn't changed. The CLI 'patch apply path_to_patch_file' and its options is still the way to apply all the patches and updates targeting the installation. Behind the scenes, the metadata describing the patch will be used to identify which layer, add-on or other component is affected by the patch being applied and to which stream the patch or update belongs.

Rolling back a patch or an update identified by its ID may require an additional argument though to identify the stream to which the patch or update to be rolled back belongs. Since every patch and update has an ID which is unique in the scope of the stream which has produced it, it's possible that patches and updates from different streams could share the same ID. To avoid a possible confusion, 'patch rollback' command now accepts a new argument --patch-stream=patch_stream_name. If --patch-stream argument is missing, the default patch stream is assumed (for backward compatibility). The default patch stream is the one identified (like it used to be in the previous versions) by the product name provided by org.jboss.as.version or org.jboss.as.product modules.

The same applies to for 'patch history' and 'patch info' CLI commands - they also now accept optional --patch-stream=patch_stream_name argument, since the patch and update history is separate for every stream.

Changes in the patching domain management model

The home address of the patching management model used to be /core-service=patching. The resource registered at that address exposed all the available patching operations such as:

/core-service=patching:ageout-history

/core-service=patching:patch

/core-service=patching:patch-info

/core-service=patching:rollback

/core-service=patching:rollback-last

/core-service=patching:show-history

and had addon and layer as children.

For backward compatibility, this address and model still exists in WildFly 10 and targets the default patch stream identified by (org.jboss.as.version or org.jboss.as.product modules).

Every patch stream now has its own address in the model following the template /core-service=patching/patch-stream=patch_stream_name, under which it will still have its own addon and layer as children and all the operations available under /core-service=patching except for patch operation, since this is the only operation that doesn't need an indication of the target patch stream other than the one contained in the patch metadata already available to the operation.

Info under .installation

There used to be a file called identity.conf under .installation. This file does not exist any more in WildFly 10. Instead, every patch stream now has its own patch_stream_name.conf. The .conf files have the same format and a set of properties as identity.conf in the previous versions plus one new property current-version which indicates the current version of the product maintained by the given patch and update stream.

Limitations of the implementation

• The current implementation has no means to verify the compatibility of the content coming in from different streams. It means that an update applied from one stream could potentially bring the whole installation into an incompatible state. It becomes the responsibility of the user to make sure the chosen updates bring the installation from one consistent state to the other. As a consequence, the following restriction is imposed on applying add-on patches: only the add-on patches released for the same minor version of the base (i.e. the default identity) can be applied safely in the current implementation.
• The boundaries in terms of file system paths that can be affected by a patch stream are not enforced. Any patch stream can update any part of the installation, as long as the hashes of the content match the expected values. This could potentially lead to overlapping and conflicting updates.