some related questions...
Currently the XML plans are not placed in the geronimo-assembly-1.0-SNAPSHOT.jar, they are placed in geronimo\modules\assembly\target\plan, which would only be available to those who build from the source code.
Q1. Should we be relocating the plans so they are shipped as part of the geronimo-assembly-1.0-SNAPSHOT.jar so that users of a binary release can modify things such as port numbers? This would be important if the default port is already in use.
We used to at some point and I think this is a good idea; others don't.
Q2. Are there any plans to be able to convert serialized configurations (in the config-store) back into XML plans so:
* one can see what their current system current configuration is, without having to navigate lots of screens in a management console and use text/XML tools to compare with earlier versions of plans or plans being used on another system (e.g. compare the differences between their test and production environments). Change/Configuration management staff at large organisations would probably like this ability.
* enable easier support of Geronimo or applications running on Geronimo, as users can send an XML plan to support staff that is easily readable.
* users could export plans to XML, modify them and then use them on another system
The serialized configurations contain attributes that are not easily represented as XML - for example, the EJB deployer builds GBeans representing the runtime configuration of the EJB container, which includes things like pre-built JNDI contexts, interceptor stacks, pre-compiled queries, ...
That being said, we need to provide diagnostic tools that allow people to examine the configuration of a stopped server. One thought is that certain attributes are tagged "configurable" and that they contain values that are human-readable - a bit like open MBeans. These are the ones that would normally be accessible through the console. It would also be useful to have a command line property editor that allowed things like the port number to be changed without redeploying the original plan.
One feature that is missing from the deployer (IIRC) is a Configuration import/export capability that would allow binary configs to be moved between servers.
One concept that is key here is that Configurations are binary artifacts that, just like the output from a compiler, can be managed as such. The packaging as JAR file allows them to be signed so that Change/Configuration management staff can absolutely track the provenance of a packaged Configuration from where it was built to wherever it is installed.
This is also why config id's are URIs - so that plans can be published and uniquely identified in much the same way as XML-Schema definitions. At this time, we do not consider the plans in Geronimo final and as such have not introduced any versioning for them. When we actually release final versions then we will specify version numbers for the plans used to build the release. The same mechanism is available to users for their plans and I would expect a user to whom change control was important to make use of these mechanisms.
-- Jeremy
