I've simplified things a bit. &quot;adrian(a)jboss.org&quot; wrote : | i.e. one deployer knows how to scan for bean annotations | That's already GenericAnnotationDeployer. It creates lazy metadata about classes and its annotations. &quot;adrian(a)jboss.org&quot; wrote : | one knows how to create components from a set of such annotations | (mod those that already have metadata). I'm creating metadata from annotations directly, leaving component creation to existing component deployers. | public void deploy(DeploymentUnit unit, AnnotationEnvironment deployment) throws DeploymentException | { | for (AnnotationProcessor processor : processors) | { | String attachmentName = processor.getAnnotation().getName(); | Object annotationAttachment = unit.getAttachment(attachmentName); | Object metadata = processor.createMetaData(annotationAttachment); | if (metadata != null) | unit.addAttachment(attachmentName, metadata); | | Set<Class<?>> classes = deployment.classIsAnnotatedWith(processor.getAnnotation()); | for (Class<?> clazz : classes) | { | metadata = processor.createMetaDataFromClass(clazz); | if (metadata != null) | unit.addAttachment(attachmentName + "#" + clazz.getName(), metadata); | } | } | } | And in case you want to stick your deployer in between (the one that modifies all metadata created from annotations), you can easily iterate over attachments picking only those which name starts with your annotation name. To handle (merging wise) just metadata that comes from annotations doesn't make sense. Since duplicate metadata can pop-up from anywhere - via getAllMetaData(getOutput()) - so it's should be component deployers that know how to handle it. And this must be addressed in general or not addressed at all - leading to failure on duplicate name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155341#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...