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
