2 Replies Latest reply on Apr 9, 2009 12:02 PM by Brian Stansberry

    Integration of Clustered DeploymentRepository in

    Brian Stansberry Master

      I've gotten a clustered DeploymentRepository working, providing functionality equivalent to (actually better than) the AS 4.x FarmService.[1] It's checked into trunk and Branch_5_x and is being tested via the tests-clustered-profileservice target in the testsuite. But it's not currently used in the all/default/standard configs.

      Next step is to get it used in at least "all", approach to which is the subject of this thread.

      The configuration change to make this work is in the conf/bootstrap/profile.xml file. The configuration that is needed can be seen at [2]. This is fairly different; has a different impl of the "BootstrapProfileFactory" bean plus adds three other beans.

      A couple of possible approaches here:

      A) Keep two versions of this profile.xml file in the source tree and change the build script such that the cluster-aware one gets used in the "all" config only. This is the way we used to handle the JBoss Web service's -service.xml. Downside is you have to keep the two source files in sync, which proved to be a minor pain point with the JBoss Web integration.

      B) Use the version at [2] for all the configs, all/default/standard. The way the clustered deployment repo works, this doesn't actually pull in any extra dependencies to the bootstrap. The "ClusteredDeploymentRepositoryFactory" bean has an incallback via which the HAPartition clustering support services are injected when stuff in all/deploy/cluster is deployed [3]. The clustered deployment repository only checks that the necessary clustering services are available if one of the URLs it's configured to manage actually exists. Bottom line, if you run the "default" config you won't have an HAPartition, but the clustered deployment repository won't fail/complain because you also won't have a "farm" dir.

      Personally, I think A) is the way to go; B) is a kludge that's hard to explain.


      BTW, this will be simpler in AS 6/trunk since finer-grained subprofiles will be used instead of the Branch_5_x "BootstrapProfileFactory" impl. An "all" config would include the needed beans in subprofiles; "default" wouldn't.

      [1] See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150107 for some discussions on this.

      [2] https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/resources/test-configs/cluster-profilesvc-0/conf/bootstrap/profile.xml

      [3] https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/testsuite/src/resources/test-configs/cluster-profilesvc-0/deploy/cluster/farm-deployment-jboss-beans.xml

        • 1. Re: Integration of Clustered DeploymentRepository in
          Brian Stansberry Master

          No comments, so I'm going to go with "A) Keep two versions of this profile.xml file in the source tree".

          Looking at how these files end up in the various configs, it's a bit untidy so I'm going to clean up a bit. The following current content in the server module's src/etc/conf ends up creating the content in the conf dir of each config.

          |-- default
          | |-- bootstrap
          | | |-- aop.xml
          | | |-- bindings.xml
          | | |-- classloader.xml
          | | |-- deployers.xml
          | | |-- jmx.xml
          | | |-- logging.xml
          | | |-- profile.xml
          | | `-- vfs.xml
          | |-- bootstrap-minimal.xml
          | |-- bootstrap.xml
          | |-- java.policy
          | |-- jax-ws-catalog.xml
          | |-- jboss-log4j.xml
          | |-- jboss-minimal.xml
          | |-- jboss-service.xml
          | |-- jndi.properties
          | |-- login-config.xml
          | |-- props
          | | |-- jbossws-roles.properties
          | | |-- jbossws-users.properties
          | | |-- jmx-console-roles.properties
          | | `-- jmx-console-users.properties
          | |-- standardjboss.xml
          | |-- standardjbosscmp-jdbc.xml
          | `-- xmdesc
          | |-- AttributePersistenceService-xmbean.xml
          | |-- ClientUserTransaction-xmbean.xml
          | |-- JNDIView-xmbean.xml
          | |-- Log4jService-xmbean.xml
          | |-- NamingBean-xmbean.xml
          | `-- NamingService-xmbean.xml
          |-- standard
          | |-- ear-deployer-jboss-beans.xml
          | |-- jboss-service.xml
          | `-- jndi.properties
          `-- web
           |-- jboss-service.xml
           `-- jmx-invoker-service.xml

          Without objection, I'm going to:

          1) Rename "default" to "all". This drives the creation of the "all" config and is the foundation for "default", "web" and "standard".
          2) Replace all/bootstrap/profile.xml with the clustered version.
          3) Create a new default/bootstrap folder containing the non-clustered profile.xml.
          4) Change the build/build.xml to use 3) in the "default" config, inherited by "web" and "standard".
          5) Create a new "minimal" dir under conf.
          6) Move bootstrap-minimal and jboss-minimal to it (and rename them), rather than leaving them grouped with "all".
          7) Change build/build.xml to reflect 6) in the "minimal" config build.

          Basically, make the organization of the files reflect the way build/build.xml consumes them.

          • 2. Re: Integration of Clustered DeploymentRepository in
            Brian Stansberry Master

            The above reorg is done:


            The "all" config is using the cluster-capable "BootstrapProfileFactory" bean.