Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 25 Jul 2005 20:12:19 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Re: GBeans: Saving Changes
In-Reply-To: <90257A22-4C48-4404-90CD-0B70DE239522@iq80.com>
Message-ID: <Pine.LNX.4.58.0507252009010.15627@saturn.opentools.org>
References: <Pine.LNX.4.58.0507242238240.22951@saturn.opentools.org>
 <42E557AB.2030201@apache.org>
 <Pine.LNX.4.58.0507251939001.15627@saturn.opentools.org>
 <90257A22-4C48-4404-90CD-0B70DE239522@iq80.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	As far as the Tomcat/Jetty thing goes, that will be interesting to
explore as we think over how we should deal with interfaces in "some
future release".  I mean, I think our dependencies should ideally be
expressed as "I require a servlet 2.4-compatible web container" not "I
require the configuration named o/a/g/Server".  Though to Jeremy's point,
I can also see that if you get everything working "just so" with Jetty
version X, you may not be all that eager to have your production team
deploy it onto Tomcat instead just because that's a compatible interface.  
I guess we need to put some more thought into exactly what use cases we're
trying to support.

Aaron

On Mon, 25 Jul 2005, Dain Sundstrom wrote:

> 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
> >>
> >
> 
>