The problem seems to persist even when the config service is pulled into its own ear and made a dependency for the component in another ear - the config service is blocked until after the timeout occurs in the dependent component (which is in a separate ear).
Please note that this only manifests itself at the container startup; once started, the components (different ears) can be re-deployed without a problem.
That seems like a regression to me. Comments?
Some more revelations. Apparently, the container simply blocks all requests, both internal and external, until after the deployment. This behavior is the result of the new feature introduced in WF11, called "graceful startup". There appears to be no way to revert back to the original, pre-WF11 behavior, and so it became impossible to (cleanly) deploy components in the same container that depend on each other by the way of HTTP requests, whether within a single ear or separate.
Does anyone have any ideas or suggestions? Kind of boring to talk to myself...