0

I'm having a problem with building a custom Wildfly26 (26.1.2) image.

The server starts normally but as soon as its fully started, it redeploys all the ears and so restarts itself.

I've broken down the problem to the deployment-scanner: I am mounting my ears from my windows host via the -v flag into the container. Everything works as expected and the server starts with the message WildFly Full 26.1.2.Final started in 106408ms. After that it immediately destroys everything and tries to redeploy the ears due to an update action. I can't figure out where this update action is coming from.

Debugging the server does show a message that it redeploys the ears but not why:


DEBUG \[org.jboss.as.server.deployment.scanner\] (DeploymentScanner-threads - 2) Deployment scan of \[/opt/jboss/wildfly/deploy/.\] found update action \[{
"operation" =\> "redeploy",
"address" =\> \[("deployment" =\> "something.ear")\],
"owner" =\> \[
("subsystem" =\> "deployment-scanner"),
("scanner" =\> "dev.profile.scanner")
\]
}\]

My Deployment-scanner config:

/subsystem=deployment-scanner/scanner=dev.profile.scanner:add(path=./,relative-to="deploy.dir",scan-interval=5000,auto-deploy-zipped="true",auto-deploy-exploded="true", deployment-timeout="18000")

If I copy the ears to another directory within the container on entrypoint, everything works as it should and it does not behave like that.

I am guessing its related to the volume mount from my host to the container.

Any help is appreciated.

If I copy the ears to another directory within the container on entrypoint, everything works as it should do. The problem here is that the deployment scanner checks the sources in the copy-destination which aren't changing because the copy command is only run once at the beginning (entrypoint). In this case the deployment scanner would be useless.

fbec76
  • 1
  • 1
  • It would likely be better to not use the deployment scanner for cases like this and deploy your application another way. You can open the 9990 port in Docker to enable deploying via the management endpoint. – James R. Perkins Nov 02 '22 at 15:56
  • The issue with this probably was the mounting from the windows host. I now just used the workaround of copy the mounted folder to a folder within the docker container. This makes the deployment-scanner obsolete but its an acceptable solution. – fbec76 Mar 16 '23 at 15:36

0 Answers0