geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: GBeans: Saving Changes
Date Mon, 25 Jul 2005 23:56:06 GMT
	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
> 

Mime
View raw message