Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 27 Jul 2005 00:34:30 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Re: GBeans: Saving Changes
In-Reply-To: <42E6EF15.7010409@apache.org>
Message-ID: <Pine.LNX.4.58.0507270002060.23546@saturn.opentools.org>
References: <Pine.LNX.4.58.0507242238240.22951@saturn.opentools.org>
 <42E557AB.2030201@apache.org>
 <Pine.LNX.4.58.0507251939001.15627@saturn.opentools.org>
 <42E59B4E.6070105@apache.org> <0a86052ced8d9c54d70e001c840995d7@gluecode.com>
 <Pine.LNX.4.58.0507261500450.22350@saturn.opentools.org>
 <42E6A162.20400@apache.org>
 <Pine.LNX.4.58.0507261715360.23546@saturn.opentools.org>
 <6a55a4b8c80c32cb2993015b7487eff4@gluecode.com>
 <Pine.LNX.4.58.0507261728330.23546@saturn.opentools.org>
 <7c430098b6c9e4be71e5e5468a9a7e27@yahoo.com>
 <Pine.LNX.4.58.0507261748360.23546@saturn.opentools.org>
 <42E6BAF2.6070701@apache.org>
 <Pine.LNX.4.58.0507261845360.23546@saturn.opentools.org>
 <42E6C5FA.6010108@apache.org>
 <Pine.LNX.4.58.0507261945560.23546@saturn.opentools.org>
 <41659cc78782817cae14170281ca1490@gluecode.com>
 <Pine.LNX.4.58.0507262007150.23546@saturn.opentools.org>
 <42E6EF15.7010409@apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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

> 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
optionally:

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

Aaron

> 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 
> listeners.
> 
> 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 
> bundles.
> 
> 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.
> 
> --
> Jeremy
>