10:05 p.m.
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
12:21 a.m.
Weird, I'm pretty sure this was working at one point...
On 25 Jun 2011, at 21:05, Scott Stark wrote:
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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:30 p.m.
Scott, are you using latest trunk ?
Latest trunk should not be adding any Filesystem picked up deployments to standalone.xml
avoiding any conflicts.
/max
On Jun 25, 2011, at 22:05, Scott Stark wrote:
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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
3:40 a.m.
No, this is an earlier version, at least a couple of weeks ago at this
point. I'll retry the scenario in question with the latest trunk.
On 6/26/11 10:30 AM, Max Rydahl Andersen wrote:
Scott, are you using latest trunk ?
Latest trunk should not be adding any Filesystem picked up deployments to standalone.xml
avoiding any conflicts.
/max
On Jun 25, 2011, at 22:05, Scott Stark wrote:
> 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
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
8:35 a.m.
The current head behavior does not update standalone.xml with the
deployments information, so the scenario in which the deployments
directory is updated when the server is not running does not fail.
Because of that I don't really need this 'undeploy *' feature now.
On 6/26/11 6:40 PM, Scott Stark wrote:
No, this is an earlier version, at least a couple of weeks ago at
this
point. I'll retry the scenario in question with the latest trunk.
On 6/26/11 10:30 AM, Max Rydahl Andersen wrote:
> Scott, are you using latest trunk ?
>
> Latest trunk should not be adding any Filesystem picked up deployments to
standalone.xml
> avoiding any conflicts.
>
> /max
>
4694
days inactive
4696
days old
4 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
Pete Muir -
Scott Stark