8 Replies Latest reply on May 25, 2005 8:28 PM by Adrian Brock

    Installer and release artifact issues

    Scott Stark Master

      To date the release process has been a simple copying of the ill defined module aspects into the release distribution structure. In working on an installer that allows for selection of specific services + customization of said services. The current build artifacts have several problems for this type of install:

      1. The current jars and descriptors are too monolithic. For the jars this means uneccessary size and dependencies. For the descriptors this means service configurations are combined that disallow finer grained installations.

      2. The conf/jboss-service.xml has a number of services that significantly increase the minimal footprint. Either this needs to be stripped down to a minimal view (just the hot deployment service), or services that are candidates for static configuration would need a mbean descriptor artifact fragment to allow for inclusion into the conf/jboss-service.xml as part of the install.

      3. Some optional services need to be registered before others. The binding service and jsr77 service both operation as listeners of mbean registration events and need to be registered before any services that they should intercept. This is not a functional dependency that can be addressed with a depends tag. These services should really be custom interceptors on the SARDeployer.

      4. Customization of the selected services is not a notion that exists in the current release build process. Post installation steps like configuring scoped classloading, call by value invocations, security, a custom datasource, enabling SSL, etc. are all configuration steps that would require the component artifacts to identify the configuration elements that should be transformed along with the variables availble. Something like velocity templatized descriptors along with supported varaibles would need to be declared.

      None of this is specific to a gui based installer. The existing testsuite makes use of custom installs of the server based on hard-coded transformations of an existing configuration with overrides of selected service descriptors/config files based on the testsuite/src/resources/test-configs contents. This should be viewed as an installation of selected components with customization of the components.

      The issue for the new build is how to support fine grained installation and configuration of a selection of components from both ant driven and gui based installers.

        • 1. Re: Installer and release artifact issues
          Adrian Brock Master

          I'll answer each issue individually. We should probably fork off some issues
          into different threads otherwise the arguments will be unfollowable.

          "scott.stark@jboss.org" wrote:

          1. The current jars and descriptors are too monolithic. For the jars this means uneccessary size and dependencies. For the descriptors this means service configurations are combined that disallow finer grained installations


          I couldn't agree more.


          4. Customization of the selected services is not a notion that exists in the current release build process. Post installation steps like configuring scoped classloading, call by value invocations, security, a custom datasource, enabling SSL, etc. are all configuration steps that would require the component artifacts to identify the configuration elements that should be transformed along with the variables availble. Something like velocity templatized descriptors along with supported varaibles would need to be declared.


          Please, no scripting framework. If we are going to support something lets
          do it as a first class notion rather than hacking another indirection.

          ant -> velocity -> deploy -> sar deployer -> binding service -> mbean -> pojos

          Many of the problems come from badly (hardly) thought out configurations, abstractions
          and implementations. Providing default policies that can be overridden/swapped
          rather than having to specify things explicitly would solve a lot of problems.

          e.g. There should be a separate "service" for the default classloading policy(ies)
          without this having to be declared in a number of different services
          (it still could be if you wanted to, but in most circumstances you don't).

          The other issue is designing the configuration to be extensible and backwards/forwards
          compatible. Which is also something a default policy provides.

          e.g. Should I really need to go through the whole of standardjboss.xml to change
          from jrmp to https for EJBs?

          An example of bad design is the JMS JDBC2 service, which should be using
          the mapping defined against the datasource.

          • 2. Re: Installer and release artifact issues
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:

            2. The conf/jboss-service.xml has a number of services that significantly increase the minimal footprint. Either this needs to be stripped down to a minimal view (just the hot deployment service), or services that are candidates for static configuration would need a mbean descriptor artifact fragment to allow for inclusion into the conf/jboss-service.xml as part of the install.


            The only reason conf/jboss-service.xml is not just the URLDeploymentScanner
            is because some default policies need to be set (like the RMI codebase
            needs to be set before JRMP is used)
            and more importantly, not all depdencies (some of which are really optional)
            are explicitly declared
            e.g.
            EJBs -> TM
            EJBs -> JCA
            EJBs -> DataSource
            EJBs -> JMS
            Invokers -> TM
            and similar for TC5

            • 3. Re: Installer and release artifact issues
              Adrian Brock Master

               

              "adrian@jboss.org" wrote:
              More importantly, not all depdencies (some of which are really optional)
              are explicitly declared


              And I didn't mention the most obvious/pervasive one, which is JNDI.


              • 4. Re: Installer and release artifact issues
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:

                3. Some optional services need to be registered before others. The binding service and jsr77 service both operation as listeners of mbean registration events and need to be registered before any services that they should intercept. This is not a functional dependency that can be addressed with a depends tag. These services should really be custom interceptors on the SARDeployer.


                The main issue here is a lack of support for cross-cutting in the current JMX kernel
                deployment, i.e. the ability to override/enhance deployments by adding advices
                to the deployment process.
                I don't like the XMBean interceptor approach, because it isn't really pluggable
                in terms of hot deployment or only including advices for services/policies that are deployed.

                • 5. Re: Installer and release artifact issues
                  Adrian Brock Master

                  Forgetting the implementation details within JBoss for the moment.
                  The issue for the build is to make available a "database" of configuration.
                  This database should include something like:

                  * The available components
                  e.g. jms
                  * The jars required to support the components
                  e.g. jbossmq.jar
                  * The mandatory config for a component
                  e.g. jbossmq-service.xml
                  * Optional/alternate config for a component (and the default)
                  e.g. hsqldb-jdbc2-service.xml + alternates
                  * Extra config/jars for a component
                  e.g. jms over http requries the httpil servlet
                  * The policies used by the component
                  e.g. jms message cache should use a caching policy or memory config/info

                  For JBoss5 I want to differentiate
                  the generic idea like jms or jms persistence
                  and the specific implementation like jbossmq or jdbc2
                  and also group components into something that can be easily referenced
                  like "I want jms" rather than I want these five config files.

                  • 6. Re: Installer and release artifact issues
                    Scott Stark Master

                    Ok, but you are talking about the correct way to do this in jb5. I need to do this in 4.0.3 so there is going to have to be some hacking like xmbean interceptors and a scripting framework.

                    In terms of a configuration database, one of our current problems is that we mix configuration and definition. This can be factored out, and layered into defaults, server settings, domain settings, etc. I still don't know how this gets mapped to a command line or gui driven installation. For example using the jms service:

                    - there is a security configuration and associated service
                    - there are one or more transport layers with additional dependencies on other services as in the case of http
                    - the choice of a persistence service can cascade to jca and a datasource configurations and services
                    - etc.

                    At one extreme with a user driven install where every component needs to be customized to a setting different from the default views of the configuration and and wizard chains are needed. The other extreme is a testsuite target definition that simply lists the required services that are needed to procude a server install using the defaults. This testsuite usecase is what we need first.

                    • 7. Re: Installer and release artifact issues
                      Adrian Brock Master

                      I forget to add a comment...

                      We are not just talking about an installer, we are talking about a consistent view/technology
                      across ant/installer/testsuite/deployers/admin-console/web-console/jsr88/etc.

                      • 8. Re: Installer and release artifact issues
                        Adrian Brock Master

                         

                        "scott.stark@jboss.org" wrote:
                        Ok, but you are talking about the correct way to do this in jb5. I need to do this in 4.0.3 so there is going to have to be some hacking like xmbean interceptors and a scripting framework.

                        In terms of a configuration database, one of our current problems is that we mix configuration and definition. This can be factored out, and layered into defaults, server settings, domain settings, etc. I still don't know how this gets mapped to a command line or gui driven installation. For example using the jms service:

                        - there is a security configuration and associated service
                        - there are one or more transport layers with additional dependencies on other services as in the case of http
                        - the choice of a persistence service can cascade to jca and a datasource configurations and services
                        - etc.

                        At one extreme with a user driven install where every component needs to be customized to a setting different from the default views of the configuration and and wizard chains are needed. The other extreme is a testsuite target definition that simply lists the required services that are needed to procude a server install using the defaults. This testsuite usecase is what we need first.


                        Yes, it is not an easy problem. There are competing requirements between
                        for example:
                        * Just use my only configured DataSource you stupid *$%@
                        * Use this explicit DataSource, I want control!!!!

                        At least those two extremes (monomorphorisms and explicitness) are well understood.
                        Things inbetween can get very fuzzy :-)