Bug 984649 - Make sure we use the latest version of JGroups
Make sure we use the latest version of JGroups
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.8
Unspecified Unspecified
unspecified Severity urgent (vote)
: ---
: RHQ 4.9
Assigned To: Simeon Pinder
Mike Foley
:
Depends On:
Blocks: 984671 987652
  Show dependency treegraph
 
Reported: 2013-07-15 11:47 EDT by Heiko W. Rupp
Modified: 2014-03-26 04:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 984671 987652 (view as bug list)
Environment:
Last Closed: 2014-03-26 04:31:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Heiko W. Rupp 2013-07-15 11:47:00 EDT
Description of problem:

We need to upgrade (if needed) to the latest version of JGroups
Comment 1 John Mazzitelli 2013-07-18 09:20:41 EDT
What we can do is under:

   modules/enterprise/server/appserver/src/main/bin-resources/jbossas

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.
Comment 2 Simeon Pinder 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:
RHQ:
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

JON:
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:
caeb7a5c832
4fa9f082b2e

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 jboss-as-module-patches.properties file that looked like
patches.old.org.jgroups.jgroups=3.2.7.Final
patches.new.org.jgroups.jgroups=3.2.10.Final

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 3 Heiko W. Rupp 2013-08-20 06:14:00 EDT
Setting this on_qa as for RHQ this has been implemented as stated in previous comment.
Comment 4 Heiko W. Rupp 2014-03-26 04:31:46 EDT
Bulk closing now that 4.10 is out.

If you think an issue is not resolved, please open a new BZ and link to the existing one.

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