Can I add wildcard name handling element to the cli undeploy command handler to allow for multiple or even all deployments (in the case of *) to be undeployed?

The usecase I have for this is how openshift express is dealing with updates to the git repository mapped to the server standalone/deployments directory. When a user does a git push of their application deployments, the server is shutdown, git repo updated, and the server started back up. Right, removal of deployments in this scenario causes the server to fail to startup with the updated deployments because the removed deployments are seen as missing on startup as show below. Because the deployments directory content is installed as one unit, all deployments fail. Installing each deployment seperately would at least allow this to work, but the cleaner approach would seem to be to remove all deployments prior to shutdown, and let the new git repo contents been seen as refreshed content to deal with.

That the server is shutdown and restarted is an express requirement that we have to deal with at this point.

root@ip-10-38-94-14 logs]# cat server.log 
01:28:23,215 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Starting deployment of "ROOT.war"
01:28:23,246 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
01:28:23,266 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."ROOT.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ROOT.war".STRUCTURE: Failed to process phase STRUCTURE of deployment "ROOT.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.0.Beta6OS.jar:7.0.0.Beta6OS]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) [jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82) [jboss-as-server-7.0.0.Beta6OS.jar:7.0.0.Beta6OS]
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.0.Beta6OS.jar:7.0.0.Beta6OS]
	... 4 more
Caused by: java.io.FileNotFoundException: /var/lib/libra/c8926000a2cc4bca9d6ccb73f015b305/jbosstest/jbossas-7.0/standalone/deployments/ROOT.war (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_20]
	at java.io.FileInputStream.<init>(FileInputStream.java:137) [:1.6.0_20]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:567)
	at org.jboss.as.server.deployment.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:84)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78) [jboss-as-server-7.0.0.Beta6OS.jar:7.0.0.Beta6OS]
	... 5 more