2 Replies Latest reply on Apr 18, 2006 2:49 AM by Dimitris Andreadis

    AbstractScheduleProvide shouldn't be HASingleton

    Dimitris Andreadis Master

      I'm looking at cases like


      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.

        • 1. Re: AbstractScheduleProvide shouldn't be HASingleton
          Brian Stansberry Master

          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>

          <attribute name="HASingleton">true</attribute>

          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.

          • 2. Re: AbstractScheduleProvide shouldn't be HASingleton
            Dimitris Andreadis Master

            The HAsingleton attribute can also go away.

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