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
>
