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
