I'm not sure of the functionality on the AS 5 base platform but if you create an artifact called deploy.last it will be the last file that the deployer deploys. If you make your common.esb depend on that it may give you the deployment sequencing that you require....
Sounds like a chicken and egg type scenario
You can't have common be last to deploy if the use case esbs are depending on it... they need to deploy after common.
The answer really comes down to your application and what is intended if the gateways receive a request that cannot be fulfilled, either because the child use case has not yet, or will not, be deployed.
If the dependent esbs should always present, then the best course of action would be to split the gateway/services from common out into another esb. You can then have the external esb dependent on the internal functionality.
Of course the HTTP gateway will not be able to consume any requests until the server has been deployed, common with all HTTP requests, so your only concern appears to be the JMS gateway.
What are your restrictions?
well, yes, it is a chicken ./. egg problem I'm having here. :-)
Basically, do you have any idea how I could accomplish this "delay startup of gateways" thing?
I see no possibility to say "do not call start() upon deployment".
I could try overriding the Gateway's start(), or place a locking method where the messages are received.
But it's probably hard to oversee all consequences this has within ESB.
Failing that, I guess I have to separate the Connectors into a new .esb, that depends on all others.
But this means I have to change that dependency whenever I choose not to deploy one use case, and that is what I would like to avoid.
Ideas on "delayed startup of gateways", anyone ?