Aaron Mulder wrote:
I thought we had a mechanism in place to store the state of a
GBean after a change at runtime -- which I assume would include storing
new values for persistent attributes as well as storing the data for new
GBeans added to a Configuration at runtime (for example, if you add a new
network connector to the web container).
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
