Community

 

Ales Justin wrote:

 

 

In most cases real deployers are meant to be component deployers,
where we expect only a single attachment by that type,
hence we are able to store it under class name.

A bit of a old thread, but I happened to run into something along these lines recently and am not sure I understand how the BeanMetadataDeployer works in cases like this one. I see many deployers which do this:

public class ADeployer
{
  public ADeployer()
 {
   setOutput(BeanMetadata.class);
 }
 
 public void deploy(DeploymentUnit du)
 {
    String blahOne = "blah";
    BeanMetaDataBuilder builder = BeanMetaDataBuilderFactory.createBuilder(blahOne, SomeClass.class);
    // ... some more specifics
    BeanMetaData bmdOne = builder.getBeanMetaData();
 
 
    String blahTwo = "onemoreblah";
    BeanMetaDataBuilder  builderTwo = BeanMetaDataBuilderFactory.createBuilder(blahTwo,  SomeClass.class);
    // ... some more specifics
    BeanMetaData bmdTwo =  builderTwo.getBeanMetaData();
 
   // add both these as attachments to unit
  unit.addAttachment(blahOne, bmdOne);
 
 unit.addAttachment(blahTwo, bmdTwo);
 }
}
 

So we have ADeployer which outputs BeanMetaData. In its deploy, it attaches 2 different instances of BeanMetaData and uses some *random* unique keys (i.e. does *not* use BeanMetadata.class.getName() as the key) to add it as attachment.

I see that we have many such deployers around and strangely the BeanMetaDataDeployer is considered relevant and the BeanMetaDataDeployer ends up deploying these BMDs. How does that work (since the attachment keys are *not* the type name of the BeanMetadataDeployer's input)? Is there some specific deployer specific config that allows this to work?