The Ejb3MetadataProcessingDeployer right now runs the merged metadata through a chain of processors which are configured in MetadataUtil (ejb3-common). Any new processors, currently will have to be included in the list maintained by the MetadataUtil. This doesn't allow for cleaner way of adding new processors. For example, if a new processor specific to the no-interface component has to be added, then the following steps have to be done:

1) Update MetadataUtil in ejb3-common to include the new no-interface processor
2) Update the dependency on ejb3-common in ejb3-deployers to refer to the new version generated by step#1
3) This also doesn't allow the processor to be maintained within the no-interface component. And instead it needs to be present in the ejb3-common module for this to work.

To get rid of all these issues, we need to make Ejb3MetadataProcessingDeployer more configurable where it can dynamically pull in new processors. Ejb3MetadataProcessingDeployer is a MC bean and MC allows for "incallback" wherein the Ejb3MetadataProcessingDeployer can listen for newly installed processors (which again can be MC beans). This way, the no-interface component can create a new processor and just make it available through its own -jboss-beans.xml file and the Ejb3MetadataProcessingDeployer will pull in this new processor.

Furthermore, some processor require the DeploymentUnit (more specifically, the classloader of the DeploymentUnit) during instantiation. So ideally the Ejb3MetadataProcessingDeployer should listen for processor "factories" which are responsible for generating the processors (some of them per deployment unit).