This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 987652 - Update EAP to 6.1.1 to make sure we use the latest version of JGroups
Update EAP to 6.1.1 to make sure we use the latest version of JGroups
Product: JBoss Operations Network
Classification: JBoss
Component: Core Server (Show other bugs)
JON 3.2
Unspecified Unspecified
urgent Severity urgent
: ER01
: JON 3.2.0
Assigned To: Simeon Pinder
Mike Foley
: 984671 (view as bug list)
Depends On: 984649
Blocks: 984671 jon32-Beta-Blockers-1006862
  Show dependency treegraph
Reported: 2013-07-23 15:51 EDT by Simeon Pinder
Modified: 2014-01-02 15:37 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 984649
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Simeon Pinder 2013-07-23 15:51:49 EDT
+++ This bug was initially created as a clone of Bug #984649 +++

Description of problem:

We need to upgrade (if needed) to the latest version of JGroups

--- Additional comment from John Mazzitelli on 2013-07-18 09:20:41 EDT ---

What we can do is under:


we can check in any patch jar in the proper subdirectory that we need it. This will be included in the build automatically in the location we want.

Downstream builds (like, for example, JON) will need to do something similar if they replace the underlying AS that RHQ ships with.

--- Additional comment from Simeon Pinder on 2013-07-23 15:49:42 EDT ---

So that only covers some of the patch scenarios. Here's the larger list of that we need to handle:
1.i)One off patches: 
Ex. security update in the modules.jar component from {EAP/AS}/modules/system/layers/.../module.jar
 * This is relevant because we will continue to use Alpha builds for RHQ and it is not likely that the EAP/AS team will ever go back and patch an Alpha/Beta/etc. release.
1.ii)Versioned patches changes: 
Ex. RichFaces 3.3.3.Final -> RichFaces 3.3.4.Final

2.i)One off patches:
* Same as RHQ, but the container version here is Non-Beta. We should be able to get patches here from EAP, but these are likely to be published to the customer portal as hotfixes.  There is some latitude here to fix the issue in the product build. See BZ 972233 where we've already had to do this with a one-off build.
2.ii) Versioned patches:  
* More tricky than RHQ because the JON builds may be using 
  a) Formalized redhat brew versions. Ex. jgroups-3.2.7.Final-redhat-1.jar
  b) Imported community versions used only by JON and never formally built in brew.   

Last wrinkle is with patch updates when there is a security embargo, which means that we necessarily have to do the binary updates in our product builds only(Customer Portal releases) because formal fixes are not releasable to community until after the embargo is lifted.

In short, one off patches(1.i and 2.i) are a pita since we need to store them in our git repo(is there a better way?) but then laying down the patch is simple as described in Comment 1 in the product build.  Versioned patches are complicated for RHQ or JON builds, a)if we need to rebuild them ourselves, b)if we need to patch one of the jar modules which means removing the old jar and metadata.

The JGroups library in master has been upgraded with commits:

These patches will make it into the next 3.2.x build so future JON builds of 3.2.x are automatically patched.

I attempted to make the patching more simple for versioned patches, by
defining a simple file that looked like

However in the end the patching logic for removal of old jars and metadata would still need to be done via ant which:
i)doesn't handle looping gracefully over properties or files even with ant-contrib
ii)doesn't make conditional logic for conditionally updating elements simple.
iii)I had concerns that successful implementations of i) and ii) would not work on the build servers used by brew.

In the end I decided it was more trouble than it was worth.
Comment 1 Simeon Pinder 2013-07-23 16:02:50 EDT
This is complicated for JON 3.2.x specifically because the underlying EAP container is 6.1.0.Final which uses jgroups-3.2.7.Final-redhat-1.jar.  Typically this means that the EAP rebuilt jgroups-3.2.7.Final in brew i)with no changes or ii)with additional patches on top of the community version.  

I still do not have visibility into to know if they have any plans of rebuilding or recertifying a later build of jgroups for the 6.1.0.Final release.  If so how is that build going to be built in brew as well or just released to the Customer Portal?

When checking the brew artifacts, no new version of jgroups has been built or added recently(see below) so the formal patching for JON 3.2.x cannot be completed until we know how the vulnerability will be addressed there.*&type=maven&match=regexp

Assigning to myself but leaving this as NEW for now.  Will ping Arun to see if he has more details.
Comment 2 Arun Babu Neelicattu 2013-07-23 19:14:51 EDT
Added you to the cc list of bug 984367.

As for the EAP, the plan is to get the fix into 6.1.1.GA. Either a patched build or a later version of JGroups will be available once bug 984367 is resolved.

Hope that helps.
Comment 3 Heiko W. Rupp 2013-08-09 10:36:32 EDT
*** Bug 984671 has been marked as a duplicate of this bug. ***
Comment 4 Mike Foley 2013-09-13 18:53:15 EDT
pre-qual'd by QE on special alpha 62
Comment 5 Simeon Pinder 2013-09-18 22:49:56 EDT
There are several commits across three different git repos that were needed to make this fix work. The most significant commit is aaf8a8d695020bf to the jon-rpmspec git repository.

Moving to ON_QA as available for testing in the following ER1 brew build:
Comment 6 Simeon Pinder 2013-10-23 11:15:53 EDT
We look QE complete for this bug. The initial issue was against EAP 6.1.0.GA.  Since that time, the jgroups version has been incremented

>>ahovsepy> i see jgroups-3.2.10.Final-redhat-2.jar in jon 3.2 ER3

and more importantly the entire EAP container has been moved forward to 6.1.1.GA where this issue has already been resolved.
Comment 7 Armine Hovsepyan 2013-11-13 09:38:05 EST
having Simeon's last comment, marking bz as verified.

Note You need to log in before you can comment on or make changes to this bug.