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