geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: GBeans: Saving Changes
Date Wed, 27 Jul 2005 14:40:37 GMT
I'm listening to this discussion and trying to make sense of it so that 
I can understand how it will affect our users.  Keep in mind that I'm 
still grasping at the fundamentals of Geronimo and G-beans so this may 
be off in the weeds  (and for which I will apologize for right now).

As I think David Jencks mentioned earlier, are think there are different 
types of configuration data?  Can we list some of the specific types of 
configuration items that we are talking about and group them?  Perhaps 
that can simplify the problem. 

Here's my attempt:
First, there is "configuration" which affects the structure of the 
solution itself (let's call it "solution configuration") ... such as 
changing the access protocol, changing the J2EE container, changing the 
security service, the persistent store, etc....  These are all changes 
that have substantial impact on the nature and behavior of the server.   
These are things that I would expect of somebody that is building a 
complete solution to be concerned with and I don't think it would be a 
problem if the changes were "maven-like" and required creating a new 
bundle (ie. not hosted in the admin console for runtime changes).

Second, there is "configuration" which affects the behavior of the 
solution but not the nature of it (let's call this "server 
configuration").  These are more minor changes such as changing ports, 
hostnames, thread pool sizes, etc... This is standard end user 
configuration and items that I would expect an end user that is running 
a solution to have to "tweak" on a regular basis.  These are types of 
configuration changes where I think it would be useful to be able to 
export and then later import the configuration for another server and 
that should be persisted apart from the Gbeans.  This configuration may 
even include the set of deployed applications for the server.

If we consider these items as being fundamentally different types of 
configuration with different users then I think it might simplify the 
problem.  The "server configuration" changes should be available via the 
admin console and should not impact any G-Bean configuration as I 
understand it.   The "solution configuration" would potentially affect 
the creation of and dependencies between Gbeans and would not 
necessarily require a WYSIWYG mechanism for change such as an admin 
console.   Of course there will always be items in the "gray" area that 
are somewhere between these or may need to be changed by both types of 
users.  Items in the "gray" area could be addressed on an individual 
basis such that it would not necessarily require mutable bundles (such 
as by defining both HTTP and HTTPS connectors and enabling or disabling 
as appropriate for the configuration).

One final question I'll toss out (and possibly show my ignorance ... but 
at least I'll learn the answer :-)  ) ... Aren't the applications that 
are deployed themselves represented by Gbeans in the bundle and 
therefore the bundle is already mutable in that sense?   I read an 
article in JAX that indicated this was the case (,id,690,nodeid,147.html ).   
Is that correct or was the author mistaken?

Aaron Mulder wrote:

>	We're making progress!  :)
>On Tue, 26 Jul 2005, Jeremy Boynes wrote:
>>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.
>	True, though there are certain advantages too (like the ability to 
>start and stop all that stuff with one command).  Anyway, that's another 
>>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.
>	Agreed.
>>I have two I've given some thought to although they're not fully thought 
>>out - but hey, we're brainstorming right?
>	Yes.
>	Of the two, I like option 5 more -- and more than all the 
>UUID-based options.  I'm not sure the mutability needs to be reflected in 
>the configuration name, though -- couldn't we have non-name properties for 
>the version and mutability?  That way the start/stop command would be the 
>same and so on.  You would refer to a prerequisite by providing the name 
>and version range separately, and perhaps even indicating explicitly 
>whether you're willing to depend on a mutable version.  If you provide 
>nothing but the name, that implies "any version will do".
>	I'd propose we add a tool that can export one or more
>configurations named on the command line (or all current configs) and
> - mark them immutable
> - assign them a specific version or UUID
> - update any references between exported modules to use the new version
>   number or UUID
> - include an explicit list of all their repository references if that's 
>   at all possible (as even locking the configuration contents does not 
>   prevent them from failing due to missing repository contents).
> - sign the exported file(s)
>	Then we likewise need an import tool that can do whatever
>name-based validation we want (perhaps prompt or automatically disable any
>other configs with the same name and different version), make sure the
>repository contains all the referenced libs, and load the configurations
>into the config store.
>	Then the installer could offer a bit more flexibility, and let you
>literally install with nothing but o/a/g/System (for a "slave" node), so
>that you could then use the configuration import tool to get all the
>(immutable or otherwise) content into that server.
>	We also need the kernel to be aware of Configurations to the level 
>that it can ensure a configuration is marked mutable when a change is made 
>to any GBean in the configuration.
>	Finally, I don't have a satisfactory answer to "what if you just
>redeploy from a plan with different contents but the same name".  It
>doesn't seem all that different than making changes through the console,
>except the kernel has no way to intercept that if the configuration was
>marked immutable.
>>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.

Joe Bohn 
"He is no fool who gives what he cannot keep, to gain what he cannot lose."   -- Jim Elliot

View raw message