4

I've been looking for a way to programmatically let a deployment stop itself.

For our use case we deploy several ear's, where one is the most important one, and the others depend on it. We made certain that the important ear deploys first, and the others start deploying in parallel afterwards.

The problem we are facing is that the important ear can be in upgrade mode, which is valid.

In the ear's that start afterwards we check for the runmode, and when it is not normal, we throw a RuntimeException. The checking for every ear deployment, happens in a Singleton Startup EJB3 Bean. But when these throw a RuntimeException the deployment is still active. I would like to inform the container that the deployment should be marked as failed. Is something like this possible?

The technologies we are using are: Wildfly 10, Java-ee 7, EJB3.

I found a solution on stackoverflow which uses the commandline CLI to stop a deployment. Can a deployment stop itself? It seems to me that it should be possible to do this in the source code itself.

Any thoughts?

Community
  • 1
  • 1
Wouter
  • 1,290
  • 2
  • 16
  • 24
  • No idea on the deployment option, but wouldn't it be easier to simply provide a REST service that returns "OK" when the deployment worked and fails otherwise? – Alexander Langer Dec 01 '15 at 11:51
  • I sort of did that with the singleton solution I described. The ear2 singleton startup bean calls the ear1 (important) project and throws a RuntimeException when the runmode is not correct, but this does not mark the deployment as failed. Since the project is not undeployed, other beans (for instance scheduled) are allowed to do stuff. I would like to find a solution that checks the runmode during startup, and if not correct just fails. – Wouter Dec 01 '15 at 12:02
  • Captain obvious: Use runtime.exec() to invoke the shell command? (well not that obvious, there are some user filesystem rights issues attached to that) – Gimby Dec 01 '15 at 15:16
  • How about using the marker files and the java.io.File api? – Miles Dec 03 '15 at 08:56

1 Answers1

0

It sounds logical to me that a deployment cannot stop itself. If it could, where to should the application report that it has succesfully undeployed? To an application that does not exist anymore? The option using the CLI looks to me like the best workaround you have got.

On a side note: Why are you using multiple EARs? An EAR can contain multiple WARs and EJB, so no need to have multiple EARs right. Also, almost all projects can do with a simple WAR, I haven't used EAR's for years.

Martijn Burger
  • 7,315
  • 8
  • 54
  • 94
  • Those ear's are "clients" to the "important" ear, and are a combination of several war's, and ejb modules. I do agree that it is weird for an application to undeploy itself. But I also think that an application should be able to quit during startup, that is if the preconditions of it are not met. – Wouter Dec 01 '15 at 15:47
  • It can quit during startup. However, you are executing a Singleton bean, so it is not during but after startup. – Martijn Burger Dec 02 '15 at 06:10
  • I do understand that an ejb3 singleton startup bean is not the same as "running during startup". It is however the first place I looked to implement such a check, because it is run when the container is deploying the application. If the ejb system is not the place to implement "precondition check logic" what would be? – Wouter Dec 02 '15 at 07:18
  • The application container manager. Which is the CLI, that has no API in Wildfly. Maybe JSR 373 is going to change that, but that JSR is planned for Java EE 8, expected in 2017. https://blogs.oracle.com/theaquarium/entry/java_ee_management_api_2 – Martijn Burger Dec 02 '15 at 19:19
  • Ah I did not know about that JSR, but it does give me another angle to look at this specific problem. Thanks for the thoughts. – Wouter Dec 02 '15 at 20:35