Minor Description
ManagedConnectionFactoryDeployer adds a serviceDeployment attachment using the following code:
unit.addAttachment(ServiceDeployment.class, serviceDeployment);
This is equivelant to:
unit.addAttachment("org.jboss.system.metadata.ServiceDeployment", serviceDeployment);
When ServiceDepoymentDeployer, which extends AbstractRealDeployerWithInput, has its deploy method invoked it will call unit.getAllMetaData(visitor.getVisitorType) (line 122).
The visitor type in this case will be class org.jboss.system.metadata.ServiceDeployment.
AbstractDeploymentUnit::getAllMetaData calls getAttachments() on line 299.
getAttachments() will try to put all attachments into a new HashMap. It will first put all of the transient attachments. This will include the one added by the ManagedConnectionFactory,
so the map will contain a ServiceDeployment with a key of "org.jboss.system.metadata.ServiceDepoyment".
Next, all the transient managed objects will be put into same map. This is done with putAll. putAll will replace any existing mappings in the map. So this means that
the value for key "org.jboss.system.metadata.ServiceDeployment" will be replaced with the one from AbstractParsingDeployerWithOutput which would be added if the deployment
contained a single "-service.xml", but note that this is not true if the deployment contains multiple "-service.xml" files.
This is performed on line 370 in the method createMetaData:
// Register it
unit.getTransientManagedObjects().addAttachment(key, result, getOutput());
The result of this can be a deployment failure of dependencies. For example if you have a database initializer in a "-service.xml" which has a dependency to a datasource declared in a "-ds.xml" then the datasource will never get deployed.
A solution could be to change ManagedConnectionFactoryDeployer to add the attachment with a different name:
unit.addAttachment(getClass().getName(), serviceDeployment, ServiceDeployment.class);
