The direction I'm currently heading is to generalize the profile service DeployerAspects to build the ManagedDeployment/ManagedComponent tree from the deployment metadata. The metadata handlers would come from the deployers who handle the associated component metadata. A component handler is something like: | public interface ManagedDeploymentCreator<T> | { | public buildComponents(ManagedDeployment ctx, Set<? extends T> metaData); | } | And the *-service.xml component handler would be: | public class ServiceMetaDataManagedDeploymentCreator | implements ManagedDeploymentCreator<ServiceMetaData> | { | | public void buildComponents(ManagedDeployment ctx, Set<? extends ServiceMetaData> metaData) | { | ... | } | | } | The DeployerAspects builds up the ManagedDeployment/ManagedComponent graph by calling out to the ManagedDeploymentCreators: | public class DeployerAspects | { | /** The metadata type to ManagedComponent handlers */ | private Map<Class, ManagedDeploymentCreator> mdCreators; | ... | ManagedDeployment md = ...; | for(Class mdType : mdCreators.keySet()) | { | Set metadata = unit.getAllMetaData(mdType); | if( metadata == null || metadata.size() == 0 ) | continue; | ManagedDeploymentCreator creator = mdCreators.get(mdType); | creator.buildComponents(md, metadata); | } | There can be interaction between multiple ManagedDeploymentCreators. For example, with jca, the factories(the managed components) and properties are determined by the ManagedConnectionFactoryDeploymentGroup metadata, but there are runtime ops and stats that have to come from the ServiceMetaData of the mbeans that the jca layer currently uses as the runtime objects implementing the factories. Those mbeans should not be showing up as some manageable sar, while jms destinations currently are deployed as just a collection of mbeans. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066236#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...