Description of problem: In EAP 6, the deployment scanner will only undeploy content if it is told to do so. What this means is that if you purge a bundle all the files managed by the bundle get deleted but if any of these were actual deployments that had been deployed by the deployment scanner, they will not get undeployed. The result is that the application context may still exist or another application that may require content provided by this deployment will begin to fail because it is not aware that its dependency has been deleted. Version-Release number of selected component (if applicable): 4.4.0.JON312GA How reproducible: Always Steps to Reproduce: 1. Install EAP 6.1 standalone server and start it. 2. Start JBoss ON 3.1.2 system. 3. Import EAP standalone server into JON inventory. 4. Create a resource group containing newly imported EAP standalone resource. 5. Create new bundle called helloworld-bundle which uses jboss-as-helloworld.war from jboss-as-quickstart: Recipe: <?xml version="1.0"?> <project name="helloworld-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle"> <rhq:bundle name="helloworld-bundle" version="1.0" description="A sample bundle of helloworld.war from jboss-as-quickstart/helloworld"> <rhq:deployment-unit name="helloworld" preinstallTarget="sayHello" postinstallTarget="dodeploy"> <rhq:archive name="jboss-as-helloworld.war" exploded="true" /> </rhq:deployment-unit> </rhq:bundle> <target name="main" /> <target name="sayHello"> <property name="misc.dir" value="${rhq.deploy.dir}/misc" /> <rhq:audit status="SUCCESS" action="Preinstall Notice" info="Preinstalling to ${rhq.deploy.dir}" message="Another optional message"> Some additional, optional details regarding the deployment of ${rhq.deploy.dir} </rhq:audit> <echo file="${misc.dir}/afile.txt" append="true"><![CDATA[Hello from a provisioning bundle!]]></echo> </target> <target name="dodeploy"> <rhq:audit status="SUCCESS" action="Postinstall Notice" info="All done deploying bundle to ${rhq.deploy.dir}" message="Another optional message"> Some additional, optional details regarding the deployment of ${rhq.deploy.dir} </rhq:audit> <basename property="dodeploy.filename" file="${rhq.deploy.dir}.dodeploy"/> <touch file="${rhq.deploy.dir}/../${dodeploy.filename}" /> <rhq:audit status="SUCCESS" action="Postinstall Notice" info="Added ${dodeploy.filename}" message="The file ${dodeploy.filename} has been created in the directory ${rhq.deploy.dir}/.. which should trigger EAP to perform the deployment." /> </target> </project> 6. Deploy bundle to resource group using destination `helloworld.war`. 7. Verify the application has been deployed and is available in the EAP instance. 8. Purge the destination. Actual results: EAP will log a warning: WARN [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015006: The deployment scanner found that the content for exploded deployment helloworld.war has been deleted, but auto-deploy/undeploy for exploded deployments is not enabled and the helloworld.war.deployed marker file for this deployment has not been removed. As a result, the deployment is not being undeployed, but resources needed by the deployment may have been deleted and application errors may occur. Deleting the helloworld.war.deployed marker file to trigger undeploy is recommended. The WAR remains deployed even though it no longer exists in the deployments directory. Expected results: EAP should indicate helloworld.war has been undeployed and the deployments directory should no longer contain a file named helloworld.war.deployed Additional info: This appears to be an overall issue in the implementation of provisioning bundles within the EAP 6 plug-in. When using the deployment scanner, we still must create meta or marker files that tell the deployment scanner what to do. These markers will depend on the application life-cycle. As you can seen in the example recipe it was necessary to create the helloworld.war.dodeploy marker file just to get the bundle to actual deploy.
This will need to be looked at as part of the bundle/rift re-work that is being planned for 3.3. Re-targeting accordingly.
Although this is definitely an issue, there is not much that can be done at this point. First, JBoss ON provisioning bundles were originally implemented for platform resources as a means to push file out to the file system. In addition to pushing files out, an Ant script can also be executed to perform other tasks. These other tasks were primarily intended to make changes or update files that were pushed out to the platform's file system. For EAP 4/5, bundles worked great if using the deployment scanner service. This is because you could push files out and even manipulate the files using data from the EAP resource, and the EAP deployment scanner would pick up the valid deployments. When you reverted or purged, the files would be update or deleted and the deployment scanner would take care of things. EAP 6 however no longer used the same deployment scanner service. For EAP 6, the expectation was that you would deploy using the management API. Because bundles deal with pushing files to a platform's file-system, there is no way to have said files deployed using the management interface. However, it was realized that EAP 6 also supported a form of deployment scanner when running in standalone mode. However, this deployment scanner did not work in the same manner and didn't deploy and undeploy just because a file was created, updated, and/or deleted. Instead, a marker file has to be used. The marker file uses the same name as the deployment file but has a suffix indicating what action should be performed. For example, 'hello-world.war.undeploy' might be used to remove the 'hello-world.war' deployment. Here is where the provisioning bundle system fails. Because a revert, purge, or even an update, does not support the notion of executing specific commands or scripts related to the action being performed, there is not way to undo or even redo something is specific commands or marker files have to be created based on life-cycle. Although this is a limitation of the JBoss ON provisioning bundle system, it is not really a bug. This is more of a design or implementation issue. The result is that if EAP 6 deployments are deployed using provisioning bundles, they can not be purged or reverted. Additionally, even updates would have to be handled using special scripting tasks that take care of the '.update' or '.redeploy' marker files necessary to update an existing deployment. Based on this analysis of the issue and understanding of how the provisioning system works in JBoss ON, this issue is being closed as "won't fix."