Created attachment 478114 [details] deploy.xml that produces the infinite loop Description of problem: When running the stand alone bundle deploy tool with a recipe file that uses the <antcall> task, the tool goes into an infinite loop resulting in a StackOverflowError. This does not happen though when I deploy the same bundle/recipe through the UI. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 478115 [details] zip to be deployed by deploy.xml
Dropping the priority on this since, it only impacts the testing tool and actually pushing the bundle out works fine. (4:31:27 PM) mazz: as per: http://rhq-project.org/display/JOPR2/Ant+Bundles#AntBundles-UsingStandaloneAntBundleDeployerTool (4:31:27 PM) mazz: "This standalone Ant bundle deployer tool is used only for testing. More specifically, running this tool does not affect the RHQ Server or Agent. If you install a bundle using this standalone Ant tool, the Server and Agent will know nothing about it." (4:32:40 PM) mazz: the purpose of this tool is to test your bundles as you are developing them. it will run your ant bundle recipe and will (should) deploy the bundle propertly on your filesystem (4:33:04 PM) mazz: however, it will NOT talk to the RQH server or agent and as the docs say, neither the server nor agent know anything about what the tool did (4:33:08 PM) mazz: its ONLY for testing (4:33:29 PM) mazz: i.e. its not like the CLI - you can't deploy a bundle via this bundle test tool and expect it to show up in your bundle UI (4:34:18 PM) jsanda is now known as jsanda_afk (4:34:36 PM) mazz: the first sentence in that docs section says, "A standalone Ant bundle deployer command-line tool is provided to simplify development and testing of Ant provisioning bundles. Use this tool to help you develop and package your bundle distribution files." (4:35:39 PM) mazz: as a matter of fact, my next task is to go through this stuff and make sure it still works on both linux and windows. this is part of the solidifying of the bundle subsystem. (4:36:17 PM) mazz: I actually haven't really run that tool before (maybe once to see it run)... so as I go through it myself, I will try to document it more fully (if in fact it needs more documenting, it may not) (4:36:39 PM) mazz: there is also a bug in its windows scripts that I have to fix too ... (4:41:55 PM) jshaughn: probably obvious but although the bundles will not be known by the server, anything the script deploys could get discovered as usual. But basically the tool is just for the iterative recipe development
I'm working with the bundle deployer tool right now, so I'll assign this to me and see if I can figure it out.
The problem here is that <antcall> invokes the same build file (it seems to reprocess the tasks that appear outside of a <target> - and because RHQ has a customized <bundle> task, it gets re-invoked and does its thing (again) which ends up going in an infinite loop. I haven't analyzed this fully so I can't give a complete and detailed description of why this happens, but it does appear that <antcall> has this side-effect of again processing the <rhq:bundle> task which causes bad things. There is a workaround - that is, rather than use <antcall> to call a target within the same deploy.xml, use <ant> and put your custom targets in a separate build file. I tried this and it worked. Here's an example: In my deploy.xml, I had this as part of my deployment-unit task: <rhq:deployment-unit name="jar" postinstallTarget="useAntCall"> My "useAntCall" target looks like this within deploy.xml: <target name="useAntCall"> <ant antfile="another.xml" target="doSomething"> <property name="param1" value="111"></property> </ant> </target> Now I create a separate "another.xml" file - it sits next to the deploy.xml file (i.e. its in the same directory as deploy.xml). another.xml looks like: <?xml version="1.0"?> <project name="another" default="main"> <target name="doSomething"> <echo>inside doSomething. param1=${param1}</echo> </target> </project> When I ran the bundle deployer tool via rhq-ant, things worked fine. My bundle was deployed and I did see the "inside doSomething. param1=111" output so I know it was invoked. Thus, I would consider this a low severity/low priority bug to fix, since there is a valid workaround. If this workaround does not work for a particular use-case, please post that use-case as a comment to this issue. If it is warranted, we can then consider to raise the severity/priority of this issue and re-consider it for fixing. I will document in the wiki that usage of <antcall> is prohibited.