Oracle SOA Suite 11g Composite Fails to Load After Restart

We had an issue at one site where a specific AQ-adapter initiated SOA composite was constantly failing to load properly, leaving the composite in an indeterminate state, where it couldn't be undeployed or redeployed.  This was perplexing since there were other composites subscribing to other AQ queues that were not experiencing this startup failure.  At first this was just chalked up to a poorly installed instance of SOA Suite, but after further examination the cause became crystal clear.

When I compared the source code of the failing process to other similar ones that weren't failing on server restarts, I could tell that the issue was related to how this particular composite was calling another SOA composite for error handling (which all of the SOA composites call).  In the failing composite, it was referencing the WSDL using a URL retrieved from the Enterprise Manager console for that composite, e.g. "http://{server}:{port}/soa-infra/services/{partition}/{compositeName}/{serviceName}?WSDL".  By referencing the WSDL this way, it requires the composite be running and loaded prior to this composite requesting it, since it's requesting the WSDL from the composite itself, and not just referring to the WSDL as a static document.  There is no determinate way to predict which order SOA composites will be loaded by the infrastructure, so doing it this was typically caused issues with the composite to where it would need to be recompiled as a different version and deployed again each time the server is restarted.

To solve this, there is a preferred way and an alternate way of the above solution.  The preferred way is to store common artifacts in the Metadata Store and reference them from your composites where possible, so utility composites like an error handler's WSDL would definitely fall in this category.  For this simple project, it was determined to instead reference the WSDL as a static document living in the infrastructure independent of the composite being loaded.  To do this, we changed the WSDL URL being referenced to http://{server}:{port}/soa-infra/services/{partition}/{compositeName}/{WSDLFilename}wsdl in the composite.xml in the import section, as well as the reference/ui:wsdlLocation attribute that references the service.  However, the previous format for the URL was left in the section in the same .  

To be clear, using MDS to store these common artifacts is a better solution, but for a down and dirty quick solution this is an alternate option.