"Deploy to WildFly or Red Hat JBoss EAP" Step

Details” and this can be a different machine. We using remoting as the Management Protocol.

It works fine and gets deployed.

However on reboot of the Red hat linux box, jboss seems to be unresponsive to the new application that was deployed in the WAR file.

I have an idea what is going on – on restarting jboss, there’s a warning it cannot find the uploaded helloworld.war file:

3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.035/0.035/0.035/0.000 ms
in master node
domain controller is already running
host.xml.slave is initialized, skip
Can’t find helloworld.war under deployments directory!
Initialize domain.conf
Add preferIPv4Stack=true
start jboss
jboss (pid 20746) is running
start deploy …

I think it’s because we remote the file in from the web services box, it doesn’t save the transmitted war file. so on restart or reboot, it can’t find the war file. Has anyone experienced this?

Would you be able to provide any assistance?

We are using RH JBoss 6.3.3 and Octopus 3.17.14

on-reboot

Hi Jean-Marc, thanks for reaching out.

In the screenshot you have provided the error message Can’t find helloworld.war under deployments directory! appears to be a custom message generated by a manual check for a file that I assume was written into the init script used to start EAP. Is this correct?

If this is true then I suspect there has been some confusion around how EAP deploys WAR files.

You can copy the WAR file directly to the deployments directory, in which case the deployment scanner will recognise the new file and deploy it.

Alternatively you can deploy the WAR file via the management API (used by the Octopus steps) which does not result in anything being saved in the deployments directory. EAP will save the file in its own custom directory structure under /standalone/data/content/. You can get more information on this content repository at https://docs.jboss.org/author/display/WFLY10/Application+deployment#Applicationdeployment-ContentRepository.

There are 2 ways to solve this error:

  1. Use the Deploy Java archive step to do the file deployment. This step allows you to copy the file to the deployments directory, while retaining the ability to do variable substitution on files. However, it does mean that the server where the file is being deployed has to be accessible from Octopus.
  2. Remove the custom check for the file in the deployments directory, or replace the check with a JBoss CLI command that queries the server directly for deployments. Querying the server directly means all deployments from all locations are returned (not just the deployments directory). You can find examples of how to query for deployments in posts like this on StackOverflow: https://stackoverflow.com/questions/21928887/jboss-7-cli-to-query-all-the-deployed-applications.

Regards
Matt C