The above issue is quite old now but the problem can still occur.

We encounter the same type of issue : an automatic reload at the end of the startup, impacting singletons, repositories and so on that do not like to be reloaded.
It happens for us only under Docker when Linux volume mountings get performed over Windows.

What happens is that the JBoss deploy scanner logic detects that the last modified date of the <war file>.deployed does not match the one of the <war file> : it therefore redeploy the war. The difference is at the millisecond level.

The root cause is in the org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.
When the war is successfully deployed, the <war file>.deployed gets created and its last modified date is set with the one of the <war file>. All fine except that the File.setLastModified is OS dependent as mentioned by the Java API : the millisecond precision may be lost, which is the case here when the JDK executed within the container is accessing the <war file>.deployed hosted on the mounted volume. Windows and Linux do handle the millisecond precision on file attributes : it seems therefore that the Docker mounting layer does not (to be investigated). We do use Rancher Desktop 1.22 and also faced the same issue with D4W10 (since 2022).

To verify it if you get the same reload issue than us : change (manually) your <war file> last modified date to a timestamp with 000 milliseconds. It will not reload at the end of the startup.

Our solution/workaround so far is to change the timestamp of the war file when the docker-compose is performed (a bit tricky). Another way is to do it at war build time (tricky as well).

The best solution - a JBoss fix - would be to store the <war file> timestamp within the <war file>.deployed file and read it on each deployment scanner execution.
As such milliseconds would be kept.