JBossDeveloper

Hah, we're cross-posting. Just read your comment about "if you stop your clustering-hotdeployment directory it would shutdown also the "default" profile". OK, I'll wait for your update.

All in all, this is good stuff; pretty easy to figure out once I had a chance to poke around. :)

I mentioned in my first post there was a reason I didn't turn on HASingletonProfileManager as the way to handle deploy-hasingleton. It's because it makes the ProfileService.activateProfile() processing re-entrant which fails.

ProfileServiceBootstrap.start(Server) --> ProfileService.activateProfile("all") --> HASingletonDeployer bean starts, becomes master --> HASingletonProfileManager.activateProfile() --> ProfileService.activateProfile("deploy-hasingleton")

This fails because the validate() call in AbstractProfileService.activateProfile() fails during the reentrant call. The outer "all" Profile is still in the middle of activating, which the validate() call treats as an exception condition.

The workaround I haven't committed is to use a ThreadLocal to detect the reentrant call and skip the validate() call. That's kind of yuck, which is why I didn't commit.

Another approach would be to have the "deploy-hasingleton" profile depend on "all", but that's not clean would actually break the HASingleton semantic by forcing the undeploy of the deploy-hasingleton/ dir at the start of shutdown, rather than waiting until the HASingletonController stop phase, which does other needed work.

"emuckenhuber" wrote:

Yeah, i thought deploy-hasingleton is independent from the other profiles.
You might still want to set a dependency on a clustering-deployers profile or something like that?

The validate works. So I switched trunk to use HASingletonProfileManager instead of HASingletonDeploymentScanner.

One concern with the validate is you can get unsatisfied dependencies. Say you have a war in deploy-hasingleton. And say during the 'all' profile deploy the cluster/deploy-hasingleton-jboss-beans.xml file is deployed before jboss-web.sar. That will trigger activation of the deploy-hasingleton profile, and the war will not complete deployment pending dependency on jboss-web.sar. Not a problem, since at the end of the whole thing the dependency will be satisfied and the war will deploy. Except, the validate call during the deploy-hasingleton activation will throw an exception.

I also tried playing with you embedded config to experiment with configuring deploy-hasingleton via XML. Added a clustering.profile with all the clustering infrastructure and made it a subprofile of root.profile. Then added an independent deploy-hasingleton.profile. My hope was the latter would be registered during the bootstrap and then activated when HASingletonProfileActivator became master.

Didn't work -- the deploy-hasingleton.profile wasn't registered. ProfileServiceBootstrap only registers the 'embedded' profile and its subprofiles. Independent ones are not registered.

OT, I'm starting to think about how to use an independent profile to do farming. A farmed profile would use a different DeploymentRepository impl.

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.

"emuckenhuber" wrote:
The original idea was to have something like:
common/profiles/ and conf/profiles - where you could then basically say that all profiles in conf/profiles
are getting registered. And only the root.profile gets activated (not really sure about that yet)

independent profile is correct, although i'm not really happy with the DeploymentRepository stuff.
if you e.g. look at the FilteredDeploymentRepositoryFactory - where the repository is doing the filtering. IMHO this should actually be done by the Profile itself.

Although this would need to be registered in the bootstrap/profile-service.xml

But as said maybe profiles should be defined as <profile> <hot-deployment-profile/> <maven-profile/> <ha-singleton-profile/>
or something like that ?

Re: resurrecting DeploymentPhase, that wouldn't help with my example case of a war in deploy-hasingleton/. The missing dependency in the example is deploy/jbossweb.sar (the web server) *not* deployers/jbossweb.deployer. (One of the things the war deployers do is establish a dependency on the web server.) So, the MC knows to wait to install the war beans until the webserver is available. But validating the "deploy-hasingleton" profile won't give the MC a chance to be patient.

I did not really get what you meant with skipping the validation on a re-entrant activateProfile :-/

private final ThreadLocal<Boolean> reentrantActivate = new ThreadLocal<Boolean>();

public void activateProfile(ProfileKey key) throws Exception
{
 ...

 ProfileContext context = this.registeredProfiles.get(key);
 if(context == null)
 throw new NoSuchProfileException("No such profile: "+ key);

 Boolean reentrant = reentrantActivate.get();
 reentrantActivate.set(Boolean.TRUE);
 try
 {
 try
 {
 log.info("Activating profile: " + context.getProfile());
 controller.change(context, ControllerState.INSTALLED);
 }
 catch(Throwable t)
 {
 throw new RuntimeException(t);
 }

 // Check if the profile was activated successfully
 if (Boolean.TRUE.equals(reentrant) == false)
 {
 validate();
 }
 }
 finally
 {
 reentrantActivate.set(reentrant);
 }
}