Description of problem: I created a bundle recipe to deploy and start a JBoss EAP server. Starting the server failed. I discovered that the failure was due to run.sh not being executable. Prior to deployment however, run.sh along with the other scripts in the bin directory do have their executable bits set. Some how the file mode bits are getting lost during the deployment process. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I tried uploading the bundle I have been using for testing, but it exceeded the max size for attachments. I will attach the recipe file I was using and then later try to upload a smaller, simpler example that reproduces the bug.
Created attachment 479786 [details] The recipe I was using when I encountered the bug.
Created attachment 479790 [details] test bundle that reproduces the issue
This is a fundamental Java limitation; Java itself does not preserve file mode bits, permissions, nothing, for any of the "supported" archive types. The only way to really support this is to natively wrap infozip or some such; that's out of scope for now unless someone else indicates otherwise. I tested Ant, various Java API's, and various Java versions; yes, 1.6 and later have the ability to set executable bits on File objects now, but the ZipEntry and JarEntry classes expose no fields to get at the information; in effect, this is a first class data corruption issue on Sun's part. So the workaround is to use what jsanda suggested: <property name="eap.dir" value="${rhq.deploy.dir}/jboss-eap-5.0"/> <chmod file="${eap.dir}/jboss-as/bin/run.sh" perm="+x"/> <exec dir="${eap.dir}/jboss-as/bin" executable="run.sh" spawn="true" resolveexecutable="true"> <arg line="-b 0.0.0.0"/> </exec>