geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: Geronimo Deployment Descriptors
Date Mon, 08 Sep 2003 15:02:12 GMT

> > 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.


View raw message