Support for configuration has a skeleton into which modules can plug their own DConfigBean's. Each module can use beans from the deployment module, or define its own for module specific configuration. At this time, a skeleton is in place but not all DConfigBean's are there.
The provider plugin is based on an embedded Geronimo kernel that hosts sub-providers provided by each module (e.g. deployment does not deploy WARs itself but hands that off to Jetty). Sub-providers are define by implementing DeploymentConfigurationFactory (DCF) and matching the appropriate endpoint for the DeploymentManager. This is currently hard-coder but will eventually simply be included in the Configuration used by the kernel.
The DCF createConfiguration method is used during the configuration phase to generate the DeploymentConfiguration DConfigBean instances. It is the tool's responsibility to save/restore the configuration - it also means the tool has control over the location.
The createModule method is used by the DeploymentManager in response to distribute (and probably redeploy) to take the File/InputStream and deployment plan and generate a DeploymentModule. This currently just uses InputStream but will change to allow the use of a directory via the File API method to support unpacked local deployments.
I could not see from the spec what a "deployment plan" was so the code assumes it is whatever was written to the OutputStream by DeploymentConfiguration.save()
Stuff still needs to be added to the DCF impl to generate an 88 module id for each deployment. The RI has a 'unique-id' hack in the VDD which we might copy. What ever we use, the DeploymentModule also needs to return TargetModuleID[] to the tool for subsequent use in start/stop. These are not define yet, but will probably be the JMX name of the module's root MBean.
Finally, the early failure modes for the DeploymentManager need to be defined - it currently throws IllegalState but should probably return a ProgressObject indicating failure.
This is intended as a brief description of the current status - this is a work in progress and things may change. As always, the code is authoritative :-)
-- Jeremy
