geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: GBeans: Saving Changes
Date Wed, 27 Jul 2005 02:19:01 GMT
Aaron Mulder wrote:
> Let me try to propose some alternatives for us to consider.  Assume you
> want to make a change to the server configuration, and for whatever
> reason, NOT bundle that with your application.  This change involves 
> adding or removing a GBean, which is naturally related to the content of 
> the o/a/g/Server configuration.  You want to make this change at runtime 
> via the web console.

First caveat - o/a/g/Server is too monolithic which is contributing 
factor to these discussions. The reasons why this is a problem and how 
to start to fix it have been discussed elsewhere.

This impacts this discussion because of the clause "which is naturally 
related to the content of the o/a/g/Server configuration." Let's assume 
o/a/g/Server is made more modular; the problem does not change, it just 
gets applies to the smaller bundles.

Second caveat, change through the web console is one use case. It 
applies to small installations (desktop, single server) but is less 
applicable to larger installations, say with > 10 servers. It also does 
not apply to "headless" servers which may not be running a web container 
at all.

> Do we all agree that this is a use case we wish to support?  

I do, but as you can tell from the caveats there are other use cases I 
also wish to see supported.

skipping straight to suggestions of other alternatives :-)
> If you have any other alternatives to propose, please do so.

I have two I've given some thought to although they're not fully thought 
out - but hey, we're brainstorming right?

Option 5: We have two different bundle types, mutable and immutable. 
Mutable ones have a special ID, e.g. containing the word SNAPSHOT so 
they can be clearly identified; immutable ones have a specific version 
number e.g. o/a/g/Server/1.0-M5. Any structural modification of the 
bundle, e.g. adding a GBean, changing a reference pattern etc. makes the 
bundle mutable. We enhance the configuration manager so that it can 
handle bundle version ranges so that bundle-to-bundle dependencies are 
squishier than they are now.

So, when the deployer builds the application it could say "this 
application expects a Jetty bundle with version between 1.0.1 and 1.0.5 
or a SNAPSHOT." Modifications through the web console that require 
strucutural change convert the config say o/a/g/Jetty-1.0.2 to 
o/a/g/Jetty-1.0.2-SNAPSHOT; bundles built with a tolerance for 
mutability will still run but ones that assume a release version won't.

For desktop and small installations we do a default assembly using 
SNAPSHOT bundles; larger installations will probably build their own 
assemblies using released versions only.


Option 6: We add a "local" bundle to the runtime that is used to hold 
"stuff associated with this instance." This would be mutable and contain 
GBeans associated with this instance e.g. edge components like network 

With this model, a second HTTP connector would be added to the "local" 
bundle rather than o/a/g/Server or o/a/g/Jetty. Deployment does not 
break for portable applications which only use components from named 

For this to work we will need to fix the classloader to provide the 
import/export mechanism add will need to be able to add imports to the 
"local" configuration at runtime. We need to be careful about adding 
multiple GBeans that require classes from conflicting imports.


There may be the possibility of a combination of multiple options e.g. 
mixing "local" bundles with SNAPSHOTs or UUIDs.


View raw message