Installer friendly SARDeployer

[starksm64]

So I'm back to prototyping an installer based on the IzPack tool (http://developer.berlios.de/projects/izpack/) and it seems sufficiently capable of handling the type of installs we need. This main issue I'm seeing with trying to achieve a true cananonical installer with every service being an optional element with dependencies (which IzPack supports), is that we need to manifest the dependencies in the service descriptors in order for things to startup correctly. Right now we have a lot of implicit dependencies that just happen to be satisfied due to placement of services in the correct order in the conf/jboss-service.xml and correct naming of deployer/sar/*-service.xml in the deploy directory.

For the first iteration I'm just breaking up the services into their independent jars, conf files, deployment descriptors to allow for a minimal installation that supports the selected services by layering these into the dist structure. I could create an object model that reflects the service dependencies and does write out the dependencies, but this is a lot more work for the initial prototype.

Instead, I'm thinking that if the SARDeployer just accepted a dependency graph in terms of the service names, that could be used instead in a less intrusive fashion. I don't see any reason why this should not work, and it might have some benefit to users as well.

[dimitris]

...
Instead, I'm thinking that if the SARDeployer just accepted a dependency graph in terms of the service names, that could be used instead in a less intrusive fashion. I don't see any reason why this should not work, and it might have some benefit to users as well.

What the SARDeployer would do with this ObjectName dependency graph?

[starksm64]

It would just populate a mapping of service to service name dependencies that would be joined with any explicit dependencies that are declared by the service when its deployment descriptor is processed.

In looking more at the IzPack architecture, it may already have all I need to do the install time depends statement injection because it has a callback mechanism and a dependency graph that may allow for obtaining the list of service object names the service being installed depends on. I'll look at this after I verify that I can setup a jboss configuration with every service component can be broken out as hot deployable into a seperate deployment with dependencies. I have already run into one problem with dependency injection of a typed proxy.

[starksm64]

So I have a default config starting up correctly using a conf/jboss-service.xml that only includes the Log4jService and URLDeploymentScanner. There were many missing dependency statements on the naming service, but with those added everything deploys in the correct order.

[dimitris]

Maybe ServiceBindingManager should be there, too. (?)

I remember somebody wanted to override the Log4Service and it only worked with it appearing first.

[starksm64]

This is an issue I'll deal with latter because the problem is that the ServiceBindingManager is an optional service, that if enabled needs to be first, but its not really a functional dependency. Really its just a configuration change to the service layer handling of attributes. More properly this should just be an interceptor+configuration of the SARDeployer, not an independent service as it would not even work without the code level integration inside of the ServiceConfigurator.

[aows]

where could i find the source for your installer module? (not the izpack sources, but the xml and scripts you used to create it and that perform any installation actions)...

Thanks!

[starksm64]

It does not exist in cvs yet.

[aows]

i don't have a windows box, but, does it install jboss as a service in windows?

We have a product we are distributing with jboss... On my spare time i'm building an installer with izpack and the plan is to install jboss as a service... If your installer does it, i would like to see how, and if it doesn't well, i'll get around it and may be able to contribute that...