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.

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.

Setting this on_qa as for RHQ this has been implemented as stated in previous comment.

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.