geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: GBeans: Saving Changes
Date Mon, 25 Jul 2005 23:59:21 GMT
I have been thinking about this issue for months now and haven't come  
to any good solutions.  I think it would be cool to have imutable  
configuration, but just think it is practical at this point.  The  
console and the tomcat/jetty selection issues really show off where  
our current design falls short.  Anyway, I haven't come up with  
anything to solve the overall problem, but I think allowing GBeans to  
be added and removed from a configuration is better then what we have  
today, so I'm +1 for it.

If someone has a better idea we can add in short term 1.x timeframe,  
please speak up.  Otherwise, I say make configuration mutable and we  
can make them immutable in 2.x when something better comes along.

-dain

On Jul 25, 2005, at 4:56 PM, Aaron Mulder wrote:

>     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