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)
Message-ID: <42E6BAF2.6070701@apache.org>
Date: Tue, 26 Jul 2005 15:36:34 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: GBeans: Saving Changes
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>
In-Reply-To: <Pine.LNX.4.58.0507261748360.23546@saturn.opentools.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit

Aaron Mulder wrote:
> 
> 	Maybe I've been casting this entire discussion in the wrong way.  
> Both changes to GBean properties and adds/removes of GBeans can be
> accomplished by adjusting the "current state" saved *in addition to* the
> original state -- so at the end of the day, we're not really altering "the
> configuration", we're preserving the original configuration and altering
> our "current state for the configuration".  Perhaps we're in violent
> agreement.  :)
> 

Almost but not quite.

The problem comes with which version of the state is used by things like 
the (runtime) deployer to build new configurations.

If it uses the "original" then the new configuration may not run with 
the "current" one; if it uses the "current" then it may not run on a 
server using the "original" one.

This may never become apparent if the configurations are never moved 
between servers. However, being able to do that was half the point - 
e.g. build the bundle on a master node in a cluster and then 
automatically push it to worker nodes.

It is also a requirement for offline or in-Maven packaging where the 
deployer will be using the "original" version and not the "current" 
modified one.

This is not a question of whether it is technically possible to make 
bundles mutable - the construction phase gets much easier if they are. 
It is whether they are usable by anything else after they have been mutated.

I think we all agree that modifying attribute values and persisting the 
changes is a good idea. David has proposed saving this separately from 
the internal structure of the bundle and that seems like an idea worth 
exploring. I'd go further and suggest we separate bundle level 
properties from component level ones (at least for this kind of 
management) but that is something we really haven't discussed at all.

Where we still seem to disagree is on whether structural changes to the 
bundle are a good idea. So far I haven't seen any solution that allows 
this and addresses the technical problems raised above and don't think 
we should go down this route until we have consensus.

--
Jeremy