> > Are there any spec requirements that must be considered? > > > Jeremy and I could not agree if there were or not :-) > > I think that it is agains the spirit (if not the letter) of the > spec to ignore the contents of a standard DD just because of the > presence of a vendor DD. > > Jeremy thinks that it is not, as he sees the generation of the > vendor DD as being part of the deployment step. > > But if we do go with Jeremies model, we have agreed that the > standard DD must at least be check for consistency with the > geronimo DD - so it will not be ignored. >
To clarify, I think the spec defines deployment as the process of taking a generic (vendor-neutral) assembled application and getting it to run on a platform. The [J2EE] spec sub-divides this into three tasks: Installation, Configuration and Execution [pp 17]; the Deployment spec [88] keeps the same concepts in a different order: Configuration, Distribution and Start [pp 8]. This latter makes more sense in a clustered environment. I believe that the Deployment Descriptors are the standardized input to the Configuration process. The specification does not define what a platform's configuration data looks like, allowing solutions such as WebLogic's where is it stored in the archive as XML files, or solutions such as WebSphere's where it is stored in a configuration repository. There is no requirement for the platform to read the deployment descriptor itself at runtime; a platform may choose to do so (especially if that is the sole location for configuration information, e.g. BEA or JBoss) but it is not required. This allows us, if we wish, to pre-compile the configuration information into other forms. For example, it could be an archive of serialized MBean states that can simply be unmarshalled by the server and started. This has many potential advantages, such as reducing the startup time for very large applications or reducing the resources required for an embedded server. -- Jeremy
