AbstractScheduleProvide shouldn't be HASingleton

[dimitris]

I'm looking at cases like

http://jira.jboss.com/jira/browse/JBAS-3082
http://jira.jboss.com/jira/browse/JBAS-2615

I think our current implementation of the ScheduleProviders being HASingletons, is a bad idea. It puts a dependency on jbossha.jar even if we don't want cluster support, and all we want is a callback when the node becomes/stops being the master.

It is much simpler to not extend HASingletonSupport and just deploy the descriptor with the schedulers in deploy-hasingleton, or leave in ./deploy and put a dependency on the Barrier controlled by the HASingletonDeploy

see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=74958


I believe this will simpify things, so if there are no objections I'm going to change it.

[brian.stansberry]

So in the schedule-manager-service.xml, SingleScheduleProvider MBean you'd replace:

<attribute name="HASingleton">true</attribute>
<attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
<depends>jboss:service=${jboss.partition.name:DefaultPartition}</depends>

with

<attribute name="HASingleton">true</attribute>
<depends>jboss.ha:service=HASingletonDeployer,type=BarrierController</depends>

That sounds fine to me. The old way of having a binary dependency on jbossha.jar for a class supposedly usable in the default config is definitely no good.

Moving schedule-manager-service.xml to deploy-hasingleton I don't like (and I don't think you proposed this). As you say, doing things that way is however another option for user deployments.

[dimitris]

The HAsingleton attribute can also go away.

So the schedule providers are cluster unaware, until you add the following dependency:

"jboss.ha:service=HASingletonDeployer,type=Barrier"