Blueprint property placeholders are not substituted reliably from Fabric8 profiles on container start

Issue

In a Fabric8 environment, Blueprint property placeholders in a Camel route will be substituted with values taken from Fabric8 profiles; this is a common, and recommended, way to provide configuration information to routes. Sets of configuration values are grouped into Persistent IDs (PIDs). A problem may be observed when Camel routes in distinct OSGi bundles read values from the same PID.

Sometimes, when the container starts, values may be substituted incorrectly. The problem may be hard to recognize because in most cases the substituted values will be used by the application, and the effect of the failed substitution will depend on the application. At the Blueprint level, the value read will either be the default specified in the Blueprint XML -- if there is one -- or an unsubsituted placeholder string like ${hostname}.

The problem is unlikely to arise on every container restart, and further restarts may appear to clear the fault, at least in the short term.

A similar problem affects stand-alone (non-Fabric8) containers -- see article [3250831][https://access.redhat.com/solutions/3250831] for more information.