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 23:48:37 GMT
	Okay, I think we're getting to the root of this.  You believe I am 
proposing breaking a current feature.  I believe I am proposing only 
adding new features without breaking anything.

	If we add the ability to add/remove GBeans to a configuration at
runtime, then based on the current HEAD, which feature will that break?

Thanks,
	Aaron

On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> Aaron Mulder wrote:
> > 	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.  
> 
> Yep, that was one of the design goals when we started on this, er, two 
> years ago. And there are other servers that do this kind of thing, 
> WebSphere-ND is one.
> 
> > 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.  
> 
> None of these interfere with 1-server support. There's just no need to 
> break N-server support that is already there whilst doing so, especially 
> when people have already stated to talk about adding clustering support.
> 
> > 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.
> > 
> 
> No one is advocating not making any changes so please do not over 
> dramatize the discussion.
> 
> What doesn't make sense is breaking features we have now for a solution 
> we have already identified has problems, planning on a refactoring say 
> within 6 months to a mode that can't use the interim solution as there 
> is no guarantee of consistency.
> 
> Why not start the discussion on how to impove what we have e.g. by 
> providing bundle level properties, by separating out management 
> properties into an human-readable database rather than burying them in 
> the config store, by separating manageable attributes from unmanageable 
> ones used for wiring purposes, by adding bundle metadata?
> 
> > 	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.
> > 
> 
> That is a different problem - we didn't "break" your EJB, it failed 
> because it could not connect to the database. The same problem would 
> occur if the DBA changed the database password or took it down for 
> maintenance. This is just a regular operational problem.
> 
> > 
> >>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.
> > 
> 
> Because it may be on a different machine, for example.
> 
> > 
> >>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.
> > 
> 
> Perhaps we should look at it now - it may make things simpler.
> Well, after M4 of course :-)
> 
> --
> Jeremy
> 

Mime
View raw message