Bug 638730 - possibility to chose the format (exploded/zipped) of archive when using <rhq:archive> in a recipe provisioning
possibility to chose the format (exploded/zipped) of archive when using <rhq:...
Product: RHQ Project
Classification: Other
Component: Provisioning (Show other bugs)
All All
high Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2010-09-29 14:54 EDT by Rafael Soares (Tuelho)
Modified: 2013-09-02 03:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-09-02 03:14:53 EDT
Type: ---
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 Rafael Soares (Tuelho) 2010-09-29 14:54:20 EDT
Description of problem:
When you use the tag <rhq:archive> in a RHQ recipe provisioning for zip/jar files RHQ extract the content inside the destination path. But some times you want to  a pkg in zip format like a WAR/EAR inside the App Server.

Version-Release number of selected component (if applicable):
RHQ 3.0.0/JON 2.4

Would be nice if you could have a property to instruct RHQ provisioning engine to repackaging your file after the process.

As Mazz suggested in [1] would be something like this:

<rhq:archive name="MyApp.war" exploded="false">

Additional info:
This issue was discussed on Rhq/Jopr forum in a thread [1].

[1] http://community.jboss.org/message/564109#564109
Comment 1 John Mazzitelli 2010-09-30 08:28:20 EDT
note: this would probably involve enhancing org.rhq.core.util.updater.Deployer (perhaps somewhere in or around extractZipAndRawFiles method). And of course we'd have to enhance org.rhq.bundle.ant.type.ArchiveType to add this new "exploded" attribute.
Comment 2 John Mazzitelli 2010-12-23 04:10:11 EST
master branch commit: d31fc63f7d6ea1116ef1884941ed869213fe3600

a few unit tests were created to show this working, see:


To test this feature, just create a bundle with an archive whose attribute "exploded" is set to false. After you deploy that bundle to an agent, see that the archive remains as a zip file and not exploded.

Note: if you ask to <replace> tokens in that archive, then your original zip will be exploded, its templatized files modified to have their tokens replaced, and the content will be zipped back up. This means your original zip file will be different than the zip file placed on the agent box. But this is nothing new and to be expected, just wanted to point this out since you can't just compare filesizes or MD5s of the original zip and the deployed zip.

Note2: in the above case (you are not deploying the archive zip exploded, but you do need templatized files modified with their replacement values), when we re-zip up the file, we create the zip file with individual file entries (e.g. "myfile.txt", "subdir/myotherfile.txt") but we do not explicitly add directory entries in the zip file (that is, you won't see an explicit zip entry for "subdir/"). I think this is OK, but I'm not 100% sure if other software that wants to use zips wants to see explicit directory entries. May have to revisit this if it is deemed to be a problem. FWIW, my zip utility on Fedora can read and manipulate these zips fine.

Note3: if you have no <replace> elements in your <archive> element in your recipe, we do a raw copy of the original zip to the deployed zip (we don't run it through the template engine).
Comment 3 Sunil Kondkar 2011-06-20 05:33:57 EDT
Verified on build 140 (Version: 4.1.0-SNAPSHOT Build Number: 5905b70)

Created a recipe without <replace> elements in <archive> element as below:
<rhq:archive name="test.zip" exploded="false">
Created and deployed the bundle to the agent and verified that the archive remains as a zip file and not exploded.

Aslo created a recipe with <replace> elements in <archive> element as below:
<rhq:archive name="test.zip" exploded="false">
<rhq:fileset includes="**/*.properties"/>

The app.zip has a templatized properties file (using a variable @@listener.port@@)
Created and deployed the bundle to the agent and verified that the archive remains as a zip file. And the templatized properties file within the app.zip file is modified with the replacement value.
Comment 4 Heiko W. Rupp 2013-09-02 03:14:53 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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