anonymous wrote : Basically all profiles need to declare their dependencies - this might get a bit redundant. Therefore implicit dependencies based on ordering. | | So all profiles defining deployers (maybe also mixed with some runtime beans related to it) need to be activated/deployed first. Your clustering profile would need to get deployed after this like same for a hot-deployment profile. Yes. When I was experimenting with the XML-based profiles yesterday I divided the clustering stuff into 3 chunks -- 1) the core clustering stuff, which went earlier in the chain, 2) at the end a "clustered-deployment" profile which contained deploy-hasingleton-jboss-beans.xml and 3) the independent "deploy-hasingleton" profile for the content. That's OK, but fragile. It also forces breaking things up into more fine-grained sub-profiles. It's a bit of a shame to have to do that since the MC can already properly handle the dependencies. I was going to suggest going to the approach of skipping the validation on a re-entrant activateProfile call. But that has a downside too, so I'll just put down a quick pro/con for the record/my memory: PRO: avoids need for black art in ensuring that anything that activates a profile gets put at the right point in the list of subprofiles. CON: code that makes the reentrant call doesn't get an exception if there truly is something wrong with the nested profile. E.g. if HASingletonProfileActivator on node 1 tries to start and activate the deploy-hasingleton profile, but there's a misconfig *on node 1 only*, the HASingletonProfileActivator needs the exception so it doesn't start properly. That should then result in node 2 becoming the master and deploying the content. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205032#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...