"bstansberry(a)jboss.com" wrote : | This again has a coordination aspect; e.g. bean A on node 1 expresses a dependency on bean B that will be deployed on node2. If both A and B are known, cluster-wide, to the respository, you don't want A's deployment to fail with a missing dependency just because node 2's deployers haven't processed B yet. | So by running the deployments across the cluster to the DeploymentStages.DESCRIBE phase, we know whether or not all dependencies can be satisfied. The only possible coordinator is the admin layer driving the profile service api usage. Maybe your driving at, do we want this to be an old farming deployment type of service? "bstansberry(a)jboss.com" wrote : | When I think in terms of priority order though, I'm thinking somewhat differently. To me, it's | | 1) Restoring some sort of ability to have repository information synchronized. This is really the only thing the old farming did, in a half-assed way ;). I'd like to have this for 5.0.0.GA as I don't like taking something away, even if was half-assed. | | 2) Sorting out the "coordination" issue I've been talking about. The lack of that kind of coordination IMHO has always been the biggest weakness in the old FarmService. | So I think we need to look at a FarmServiceUnitTestCase that uses the profile service DeploymentManager to validate the various types of things that can happen with a two node deployment say, and figure out what will/won't work for the initial release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153017#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...