geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 22:58:12 GMT
	FYI, I don't think this is a technical issue, I think this is a
scope issue.  You're talking about how to support "build the bundle on a
master node in a cluster and then automatically push it to worker nodes"  
and how to support features that no other app server has.  I'm talking
about how to provide a usable management environment for ONE server, which
is something we most definitely need to be competitive.  We have to get
past reasonable 1-server support (plus of course add clustering support)  
before we need the features you're describing.  I feel that we should
proceed with a short-term option and plan to refactor when we are at a
place where supporting the environment you're describing becomes feasible.  
It doesn't make sense to me to not proceed with any change until we can
solve every problem we might ever have.

	That said, back to the issue:

On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> 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 is true today; if we don't implement add/remove, we still
have the problem.  For example, you could deploy an EJB that depends on a
data source, then go change the password used by the data source to be
invalid so it doesn't start or function, thereby breaking your EJB.  This
is true of every app server that I've ever used.  I don't consider it to
be a critical flaw of the product.  But of course it would be nice to have
a way around it down the road.

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

Why won't the deployer use the current state in offline mode?  If it 
touches it at all, it should use the same "current" state that the server 
would use if it started.  Otherwise, what's the point?  This shouldn't be 
at all hard to fix if that's not the way it works today.

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

I think this is a fine candidate for later refactoring.

Aaron

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

Mime
View raw message