9.2. About Patching Mechanisms
JBoss patches are distributed in two forms: zip (for all products) and RPM (for a subset of products).
Important
A JBoss product installation must always only be updated using one patch method: either zip or RPM patches. Only security and cumulative patches will be available via RPM, and customers using an RPM installation will not be able to update using zip patches.
JBoss patches can be either an asynchronous update, or a planned update:
- Asynchronous updates: individual patches which are released outside the normal update cycle of the existing product. These may include security patches, as well as other individual patches provided by Red Hat Global Support Services (GSS) to fix specific issues.
- Planned updates: These include cumulative patches, as well as micro, minor or major upgrades of an existing product. Cumulative patches include all previously developed updates for that version of the product.
Deciding whether a patch is released as part of a planned update or an asynchronous update depends on the severity of the issue being fixed. An issue of low impact is typically deferred, and is resolved in the next cumulative patch or minor release of the affected product. Issues of moderate or higher impact are typically addressed in order of importance as an asynchronous update to the affected product, and contain a fix for only a specific issue.
Security updates for JBoss products are provided by an erratum (for both zip and RPM methods). The erratum encapsulates a list of the resolved flaws, their severity ratings, the affected products, textual description of the flaws, and a reference to the patches. Bug fix updates are not announced via an erratum.
Important
It is important to note that after a patch has been applied, the jars picked up at runtime are picked up from the
EAP_HOME/modules/system/layers/base/.overlays/$PATCH_ID/$MODULE directory. The original files are left in EAP_HOME/modules/system/layers/base/$MODULE. The patching mechanism cripples the original jar files for security reasons. This means that if you apply a patch which updates a module, the original module's jar files are altered to be unusable. If the patch is rolled back, the original files will be reverted back to a usable state. This also means that the proper rollback procedure must be used to rollback any applied patch. See Section 9.4.3, “Rollback the Application of a Patch in Zip Form Using the Patch Management System” for the proper rollback procedure.
For more information on how Red Hat rates JBoss security flaws, refer to: Section 9.6, “Severity and Impact Rating of JBoss Security Patches”
Red Hat maintains a mailing list for notifying subscribers about security related flaws. See Section 9.3, “Subscribe to Patch Mailing Lists”
