As explained in the blog entry Upgrading and patching the Red Hat JBoss Enterprise Application Platform JBoss EAP offers the possibility to conveniently update the server installation with the latest patches.
However, the way this is implemented leaves all previous versions and patches of your modules behind. I.e., older versions of the JAR files will not be used anymore, but just waste disk space. This is desirable only, if you want to have the possibility to roll back a patch later on or would like to keep track of the patch history.
To give you some numbers: The current EAP 6.4 server has an initial size of 166MB, but grows to a size of 509MB when updated to version 6.4.4. In this article we’d like to show you how to remove all unused garbage from the installation.
Step 1: Delete installation directory
We are starting from a freshly patched JBoss server in directory JBOSS_HOME (version 6.4.4). The first thing that safely can be deleted is the installation directory JBOSS_HOME/.installation. That’s just the place where the patch command unzips the patch files and stores the patch history.
Step 2: Update modules
JBoss stores the updated module versions in a hidden directory named JBOSS_HOME/modules/…/.overlays and JBOSS_HOME/bundles/…/.overlays, respectively. For example, you will find the current JARs of the Hibernate Core in JBOSS_HOME/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.4.CP/org/hibernate/main. The magic is that the server will at runtime look into the overlays directory and ignore the initially installed modules.
So all you have to do is copy the updated modules into the JBOSS_HOME/…/modules directory and afterwards remove the overlays directory. Since this quite cumbersome to do manually I wrote a little shell script which you will find at the end of this blog.
Step 3: Update two module.xml files manually
Lastly, you will have to shorten some path definitions in the module.xml files with a text editor. Currently, this is necessary for two modules: “org.jboss.as.web” and “org.hornetq”.
Simply open JBOSS_HOME/modules/system/layers/base/org/jboss/as/web/main/module.xml and change the line
<resource-root path=”../../../../../../../org/jboss/as/web/main/lib”/
to
<resource-root path=”../../../../../org/jboss/as/web/main/lib”/>
The same applies for JBOSS_HOME/modules/system/layers/base/org/hornetq/main/module.xml.
Step 4: Delete/update unnecessary/recreated files (Optional)
In order to create a really clean distribution you might also want to delete the runtime directories in JBOSS_HOME/standalone, namely
log/, data/ and tmp/
Take a look at JBOSS_HOME/standalone/configuration/logging.properties, too: The file probably contains a hardcoded handler.FILE.fileName property which may lead to confusing messages on another machine.
Appendix
Here’s the Shell script: strip-patched-jboss.sh.
It will not directly delete unnecessary directories but rename them with a XXX_DELETEME suffix.
After execution of the script and the manual edits try to start the server and if that is successful you can delete all unused files running:
rm -r `find jboss-eap-6.4.4.GA -name \*XXX_DELETEME`
It’s work fine with jboss eap 7.0.3
Note that in EAP 7 you will not have to edit the Web and HornetQ module.xml files anymore.
Why don’t you simply age-out patch history? As manually fiddling with modules structure can be dangerous.
you cleanup history that by running in cli
/core-service=patching:ageout-history
for more details see https://access.redhat.com/solutions/1269123
Hi.
Thanks for your suggestion. That solution was simply not available when I wrote this article.
Anyway, my solution still yields better results 🙂 It tested it by patching an EAP from version 6.4.0 to 6.4.7.
Patched JBoss: 849M
Your solution: 280M
My hack: 172M
The difference exists, because purging the history does not delete all older files and the patch repository in JBOSS_HOME/.installation itself.
Cheers
Markus
Thanks for this article!
The question is: Why doesn’t Redhat provide a full distribution right away?!
This approach also seems to work for the newly released patch 05 (-> 6.4.5.GA).
First I first tried to install just the 05 patch sub-archive onto a shrinked 6.4.4 but was confronted with conflicts:
[standalone@localhost:9999 /] patch apply C:\Develop\tmp\eap6.4\jboss-eap-6.4.5.CP.zip
Konflikte gefunden: org.jboss.as.osgi.configadmin:main, org.hornetq:main, org.jboss.as.web:main
Use the –override-all, –override=[] or –preserve=[] arguments in order to resolve the conflict.
Applying the full patch 05 archive (which also includes 01, 02, 03 and 04) to shrinked 6.4.4 didn’t work either:
[standalone@localhost:9999 /] patch apply C:\Develop\CCS\tmp\eap6.4\jboss-eap-6.4.5-patch.zip
JBAS016840: Patch nicht anwendbar – erwartete (6.4.0.GA), aber war (6.4.4.GA)
Finally, installing the full patch 05 archive onto 6.4.0 was successful.
Does this mean a shrinked distribution cannot be used for applying future patches?
Hello Falko,
I’ve no idea why Redhat does not support a “clean” current version themselves. May just laziness 🙂
A shrinked distribution can indeed not be used for further patches. The reason is mentioned in the article:
The “patch” command keeps track of already applied patches in the hidden .installation directory. Since we
delete that information the command will get confused and fail.