Just some follow up comments since I'm currently testing the DeploymentManager api for adding raw deployment content to a repository. So the first issue is that hot deployment is no longer really a scanner service as it was in the past. Such as service does exist, but its nothing more than a thread/executor that calls into the profile for the modified deployments. So 'hotdeployment' is purely a profile implementation detail, and how we reconcile local repositories across a cluster would be part of the org.jboss.profileservice.spi.DeploymentRepository.getModifiedDeployments() implementation. As we build out different repository implementation maybe we'll need to add more policy plugins for things like cluster synchronization. Synchronization of multiple local file based repositories as you describe is difficult for something outside of the profile service as the exact state of a deployment is the raw deployment content + any admin edits that may have occurred. Raw content sitting on the disk may not be in the profile depending on what removing a deployment from a profile actually does. The "Coordinating deployments" point is a bit confused in my view as there are a number of different aspects of a clustered application. 1) The simple notion of having a deployment available across all nodes in the cluster, the DeploymentPhase.APPLICATION_CLUSTERED notion of the DeploymentRepository. There could be an annotation for this down to a bean level rather than a coarse deployment level. We could support this using the MetaDataRepository levels and have a clustered MetaDataRepository where we just distributed the BeanMetaData(for example) for the annotated bean. Provided the deployers/deployment attachments were properly integrated with the MetaDataRepository, it should just work, but there is a dependency issue. I'm wondering if there really is a @Farmed vs a more expressive @Clustered notion though. I would think @Clustered could be a superset of @Farmed where if I only wanted distribution of a component across the cluster without any cluster aware aspects applied to the component. That type of farming/clustering seems outside of the scope of the profile service deployment repository. Its just a metadata/metadata repository issue. 2) Cluster wide dependencies between beans. Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation. 3) Clustered aware aspects. Caches, proxies, cluster-wide singletons, are behaviors that you potentially want cluster aware implementations of for components marked as @Clustered. Clustering like security is a cross cutting notion that we need the proper metadata for, and hooks to which cluster aware variations of the aspects can be applied. I agree that cluster aware deployers should not be needed. Rather, the deployer should be driven off of the metadata and component aspects to create clustered components. Identifying these aspects and making sure deployers just work when the cluster aware aspects are configured is the main task. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152811#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...