6 Replies Latest reply on Oct 30, 2008 12:11 PM by starksm64

    Towards a canonical server

    starksm64

      One thing on the agenda for next week is moving towards a canonical server configuration model where the profile service repository has one jar/deployment regardless of how many configurations its used in.

      Related tasks:
      Define initial persistent format of the profile repository
      https://jira.jboss.org/jira/browse/JBAS-3768

      OSGi Bundle Repository support
      https://jira.jboss.org/jira/browse/JBAS-4363
      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040005

      Refactor the conf/jboss-service.xml services ; should be remove conf/jboss-service.xml
      https://jira.jboss.org/jira/browse/JBAS-4814

      Split system and application deployments
      https://jira.jboss.org/jira/browse/JBAS-5954

      Re-package system deployments
      https://jira.jboss.org/jira/browse/JBAS-5955

      The first hurdle is updating the build to produce a repository of jars/deployments, and then properly describing:
      - the class dependency requirements for deployments
      - the association of deployments with profile service configurations; (minimal, default, all, ...)

      This is what I'm starting to look at. How this is split up for what gets done for the 5.0.0.GA, EAP and future 5.1 releases is an issue as well since we are pressed to get the 5.0.0.GA/EAP out.

        • 1. Re: Towards a canonical server
          starksm64

          There is also this related profile service ManagementView does not appear to see the conf/bootstrap.xml and conf/jboss-service.xml deployments and managed objects issue:
          https://jira.jboss.org/jira/browse/JBAS-5689

          • 2. Re: Towards a canonical server
            dmlloyd

             

            "scott.stark@jboss.org" wrote:

            The first hurdle is updating the build to produce a repository of jars/deployments, and then properly describing:
            - the class dependency requirements for deployments


            Are we going to be doing this generally by package or by module? I started doing some of my stuff by package but it seems to me that for (non-JEE) projects which have e.g. an API jar and implementation jar it might be better to have e.g. JBossRemotingAPI as a module, and have the implementation (as well as any user applications) simply depend on that.

            Thoughts?

            • 3. Re: Towards a canonical server
              starksm64

              Its going to have to be both. Java modules/osgi bundle type of packages of classes/resources should be declaring their version and dependencies. Then there are the deployments with their metadata/descriptors that would also have dependencies as well as private classes/resources with either no export, or limited export of the deployment classes.

              Deployments are also what would be associated with a named profile like minimal, default, all. The standalone jars should just be part of the profile repository, either used or not depending on the named profile dependencies.

              • 4. Re: Towards a canonical server
                starksm64

                I updated http://wiki.jboss.org/wiki/JBossMCProfileServiceBootstrap
                and the first issue is that we are bootstrapping a large number of core services and jars in the org.jboss.bootstrap.microcontainer.ServerImpl by loading the bootstrap.xml and its referenced classloader.xml, aop.xml, jmx.xml, deployers.xml, bindings.xml, profile.xml.

                Originally the profile service was closer to the bootstrap and the bootstrap deployments came from the profile. I guess we split this up to have more control over the order services are created. At a minimum we would need a new vfs url for the classpaths to allow the jars to come from the profile repository.

                If the deployments and their order are also to be part of the profile definition, we would need to get the BootstrapMetaData from the Bootstraps, but those don't exist without loading the profile.xml. Its not a big deal for these to be manageable initially, but what is the long term plan?

                • 5. Re: Towards a canonical server

                   

                  "scott.stark@jboss.org" wrote:

                  If the deployments and their order are also to be part of the profile definition, we would need to get the BootstrapMetaData from the Bootstraps, but those don't exist without loading the profile.xml. Its not a big deal for these to be manageable initially, but what is the long term plan?


                  The longer term plan should be to minimise the bootstrap to only what
                  is required to get a functional profile service.

                  But things have leaked into the bootstrap because of "bad" dependencies.

                  The splitting up of the bootstrap files is the first step in indentifying/reducing
                  these dependencies so they can become more normal parts of the profile.

                  e.g. all the JMX stuff should be in deployers rather than the bootstrap,
                  but then you have the problem that the @JMX advice definition is too late in the process
                  to expose all beans.
                  aop is in the bootstrap for the same reason.

                  • 6. Re: Towards a canonical server
                    starksm64

                    Since we are not going to get too far on this for the 5.0.0.GA, I want to continue to talk about what the server contents might look like in the canonical distribution paradigm.

                    The server contents would probably be something like:

                    jboss-5.1/bin
                    jboss-5.1/repository
                    jboss-5.1/server/default/profile.xml
                    jboss-5.1/server/all/profile.xml
                    ...
                    


                    The repository has deployment bundles, be they library jars or deployer contents, along with metadata about each deployment that includes things like version, capabilities and requirements. See the OSGi OBR spec http://www.osgi.org/Download/File?url=/download/rfc-0112_BundleRepository.pdf for an idea of capabilities/requirements.

                    A profile.xml should actually only be a statement of requirements that are matched up to content in the repository:
                    <profile name="default">
                     <requirement>ejb3-core</requirement>
                     <requirement>ejb3-ext</requirement>
                     <requirement>ejb2</requirement>
                     <requirement>ejb2</requirement>
                     <requirement>JMS</requirement>
                     <requirement>jmx-console.war</requirement>
                     <requirement>ROOT.war</requirement>
                     <requirement>JSR77 MEJB</requirement>
                     ...
                    </profile>
                    


                    We may need to include library version range requirements as well for applications that will be added dynamically via hot deploy.