[ https://issues.jboss.org/browse/WFLY-10315?page=com.atlassian.jira.plugin... ] Vladimir Grabarchuk commented on WFLY-10315: -------------------------------------------- No, this is not about rejecting requests with an error until the full startup; neither rejecting nor blocking will do us any good here. This is a request to restore (make possible) the legacy, pre-WF11 behavior where the use case in hand was working perfectly. Here are some more details. The config service is set to deploy first and must be able to serve requests from other components being deployed in the same container. These other components depend on the configuration data from the above service, which they try to acquire at their deployment time (that is, while the container is still starting) and fail to deploy altogether without it. The only way to satisfy this requirement post WF10 is to deploy the configuration service into a server of its own, which is wasteful and prohibitively expensive. I hope that clarifies the situation somewhat. Please consider bringing back the legacy behavior to accommodate cases like that. I don't pretend to know much about the WildFly innards, but hoping that it might be some kind of a "switch" not to block HTTP requests while the server is still in the deployment mode. Naturally, those who chose to enable this mode, should it become available, will be responsible for the correct component deployment order and would have to deal with 404 and/or other errors. -- This message was sent by Atlassian JIRA (v7.5.0#75005)