For my part, I'm not convinced that it makes sense for
configurations to be immutable. I think the export/import feature
would
be nice -- "I finally got my web container configured 'just right',
now
let me export it and load it into my cluster of 30 boxes". I wouldn't
even mind giving each configuration a unique hash or something such
that
we could eventually down the road add a feature where you export two
related configurations, and one refers to that specific build of the
other. Or even having an immutable flag on a configuration such
that once
you've marked one as immutable it refuses to change in the future.
But to tell me that properties of a configuration shouldn't ever
be changed, or that GBeans shouldn't be added or removed at runtime
and we
should create new child configurations instead... unless I'm
misunderstanding you, that just doesn't work for me. I can't imagine
someone customizing their web container and then after a few revs
they try
to load or unload or export it and discover that they now have
configurations "Server", "Server HTTP v1..v5" "Server HTTPS v1..v3"
"Server AJP v1 & v2" "Server Keystore v1..v4" "Server accept thread
pool
v1" "Server JSP Compiler v1..v3" "Server request log v1..v5", and
so on.
Much better IMHO to let them alter the "Server" configuration to their
heart's content, then let them export it or flag it as locked if
they want
to preserve a snapshot of that state.
Thanks,
Aaron
On Mon, 25 Jul 2005, Jeremy Boynes wrote:
Configuration bundles are meant to be immutable so you shouldn't be
adding things to them at runtime. Think of them as being similar to
library jars or other maven artifacts - things would get very
confusing
if you started adding classes into them as part of a build. This
allows
the configuration to be identified by its ID in the same way the
artifact id identifies a dependency to maven.
Configuration bundles have attributes (currently modeled by
exposing the
GBeans they contain which is problematic) which pertain to the
location
in which they are being used. The *default* values for those
attributes
are contained inside the bundle; the instance value is set by the
environment.
There are some implementation issues in Geronimo today (short cuts
taken
for expediency) which obscure some of the subtleties of this
model. Some
of these relate to classloading (the issues on the packaging thread),
others relate to GBean persistence.
I'll give a couple of examples which I hope highlight a couple of the
issues.
The first anti-pattern is that configuration ids are not unique - we
reuse them for different configurations. For example, although Tomcat
and Jetty based servers are quite different we use the same
"unique" id
(org/apache/geronimo/Server) for both. We also reuse ids across
versions
so it is impossible to tell if an application deployed against
org/apache/geronimo/Server was built using M1, M2, M3 or HEAD. It is
like only ever compiling against SNAPSHOT dependencies.
Secondly, if configurations are immutable then you should not be
able to
add GBeans to them at runtime (that would be mutating them). So
how do
you add a network connector? The simplest model is to separate the
web
container from its connectors and build them as separate bundles (one
for the container, one for each of the connectors); if you want to
add a
new connector you add a new instance of e.g. the HTTPS bundle.
Finally, there is the issue of instance properties - things in the
environment of where a configuration is being used that need to
override
the default properties that is has. For example, the default for the
HTTP connector bundle might be to listen on port 8080 but on this
server
here it needs to be changed to be 8888. Right now we do this by
mutating
the configuration installed in the store which is problematic.
Instead
it would be better to associate the state with the runtime and, after
the bundle was loaded but before it was started, inject those local
values into it.
There's a fine line between when you want to override values on a per
instance basis and when you want to define a new configuration for
with
those values as defaults. There's no right solution to that but I
think
the type of installation plays into it:
* for a desktop development environment or single server installation
then you are better just overriding properties as needed
* for a clustered environment or large scale deployment then you are
better defining reusable bundles that can be easily moved where/
when
they are required
As Geronimo starts being considered for larger installations let's
not
forget what the original config system was designed to do.
--
Jeremy
