Aaron Mulder wrote:
I don't understand why Jeremy's vision is incompatible with
altering configurations on the fly. That is to say, you change and
change
and change, and when it's right, you (sign and) export
"myconfig-1.3.1.jar". Perhaps that includes a single configuration
(web
container). Perhaps it contains several (J2EE server in a box,
ready to
apply to nodes in a cluster). If anyone else posts
"myconfig-1.3.1.jar"
to your download catalog, then either 1) they're an idiot (just like
if I
posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
signed with your certificate and can be recognized as a forgery. If
we
package configurations in JARs (and we haven't defined the
"interchange
format" to move configurations between servers / config stores but a
JAR
certainly seems reasonable), then they can be signed using the same
tools
that are normally avialable.
Having immutable configurations does not affect these issues. I
can name and version my configuration the same as you do even if
they were
both totally unchanged at runtime. Without some sense and/or
signatures,
there's nothing to prevent anything from conflicting. Just like we
could
post an updated set of M4 QA JARs today with the same name but
different
content.
You alude to the problem yourself without realizing it. We have an
example of the problem right now with our build system and its use of
SNAPSHOT jars.
SNAPSHOTs are mutable. Their content varies over time based on
whatever
happened to be in the source tree when they were built. If you have a
SNAPSHOT artifactId you won't know from one build to another that you
are using the same code.
To the person developing that artifact, that it is a SNAPSHOT doesn't
matter - it's output work product to them, what they are using is the
source tree.
However, to the person using the library it does matter. If they rely
on
a SNAPSHOT published to a repo they can't rely on getting the same
code
each time. If they need stability they need to use an explicit
version.
If the publisher publishes two different codebases under the same
version number then, to use your phrasing, "they're an idiot" and as a
user you start looking for alternatives. In other words, you want
released artifacts to be immutable and versioned.
To have a consistent release we can't use mutable SNAPSHOTS and we
(primarily John) are going through and replacing them with immutable
versions.
Putting this in the configuration context, when you start modifying a
configuration you are "developing" it - you're tweaking it to do what
you want. This is not a problem for you. However, it is a problem for
things that "use" that configuration and have certain expectations on
its behaviour as it is now doing what you want and not what it
advertised that it could do.
There are things in the system that "use" your configuration - the
config builders and the applications that they build are two examples.
If you mutate the Server configuration from using Jetty to using
Tomcat,
an application that was built against that configuration with the
assumption that it was Jetty will no longer work.
The HTTP connector example we are so fond of is a bad one as nothing
"uses" that bundle - it is a user of other bundles, dispatching
requests
to them but nothing actually references it. You can mutate it to your
heart's content and nothing will notice.
As an alternative, consider an example where an application contains a
message-link that uses a queue. The application builder can look at
the
server configuration, see that there is no queue there and decide that
it should define one in the application bundle. That bundle can be
moved
to any instance running that server configuration and will run quite
happily as it is taking its queue along with it. However, if the
server
configuration is mutated on some instances so that it has a queue you
now have a conflict: two queues, one from the mutated server, one from
the application. Or if the configuration is mutated to use a different
message provider then it may not work at all.
The challenge we face is finding a balance between the things that can
mutate that no-one will notice and things that should be immutable so
that they can reliably be used by others.
--
Jeremy
