Installer and release artifact issues

[starksm64]

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.

[adrian.brock]

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

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.

[adrian.brock]

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

[adrian.brock]

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.

[adrian.brock]

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.

[adrian.brock]

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.

[starksm64]

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.

[adrian.brock]

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.

[adrian.brock]

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 :-)