Dain Sundstrom wrote:
On Jul 26, 2005, at 3:36 PM, Jeremy Boynes wrote:
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.
We have this problem regardless. Any mutation in the environment or
configuration state can cause a service to not start. For example, if
a users moves an important directory, or changes a service attribute to
point to a new directory. The proposed change does not solve that
problem but it doesn't cause that problem either. When someone comes
up with a solution to this problem, we can change the console also. It
is *soft*ware after all.
There's a difference between not starting and not present. If something
doesn't start because of environmental issues then you have an
operational problem.
If the server says it offers some services (e.g. a Jetty container) but
has incompatibly mutated (e.g. into a Tomcat container) then you have a
much bigger set of problems.
The immutablity is there to solve that.
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.
The command line maven tool will load the current state from the server
configuration store. If the maven plugin doesn't do that I would
consider that a bug.
No, we've been there already (ApacheCon last year). That is coupling
offline deployment to an instance of the online system rather than
allowing it to use the advertised target environment.
The current command line tool in offline mode loads the state from its
internal config store which just happens to point to the same directory.
Ironically, this would be fine if configurations were immutable.
The plugin loads bundles as artifacts from the local maven repo - which
is fine as they are immutable - automatically giving us the ability to
publish bundles online.
--
Jeremy
