geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: GBeans and Configurable Properties.
Date Thu, 03 Feb 2005 02:11:04 GMT
sissonj@insession.com wrote:
> 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

Mime
View raw message