geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: GBeans: Saving Changes
Date Tue, 26 Jul 2005 19:37:10 GMT
	I don't understand why Jeremy's vision is incompatible with
altering configurations on the fly.  That is to say, you change and change
and change, and when it's right, you (sign and) export
"myconfig-1.3.1.jar".  Perhaps that includes a single configuration (web
container).  Perhaps it contains several (J2EE server in a box, ready to
apply to nodes in a cluster).  If anyone else posts "myconfig-1.3.1.jar"
to your download catalog, then either 1) they're an idiot (just like if I
posted log4j-1.3.1 full of Aaron code not Log4j code), or 2) it's not
signed with your certificate and can be recognized as a forgery.  If we
package configurations in JARs (and we haven't defined the "interchange
format" to move configurations between servers / config stores but a JAR
certainly seems reasonable), then they can be signed using the same tools
that are normally avialable.

	Having immutable configurations does not affect these issues.  I
can name and version my configuration the same as you do even if they were
both totally unchanged at runtime.  Without some sense and/or signatures,
there's nothing to prevent anything from conflicting.  Just like we could
post an updated set of M4 QA JARs today with the same name but different

	I'll grant you I could download your configuration and then change
it and then blame you if it doesn't work.  But I already said I don't mind
adding a flag of some sort.  And really, what are the odds that a
configuration is going to be 100% perfect?  What if the web configuration
is totally groovy but aimed at a bigger box so you want to tone down the
accept thread pool?  What if you want to change ports?  What if you prefer
Jikes?  If you must take it entirely without alteration or not at all, I
don't think that will be worth so much.

	As far as the volume of "stuff" in a configuration, we can think
of some way to disentangle class loaders from configurations.  But we have
(in my poor estimation) probably hundreds of GBeans in a server today, and
I don't think it makes sense to have tens or hundreds of configurations.  
That just means that if you want to disable some feature, you have to run
loads of commands instead of one.  And if you want to download from a
catalog, you have a lot more individual stuff to download.  It might be
useful to separate EJB out from Web and J2EE foundation, but it doesn't
bother me all that much -- we already have JMS and JDBC separate, which is
a fine start.  Not a big deal to me either way.

	I totally agree with David that it would be great to be able to 
deploy more bits as parts of an application.  I think it's pretty
desirable to be able to deploy connectors as part of an application, so 
you can bundle your DB pool or JMS destinations with your app.

	However, I don't at all think it makes sense to claim that
replaces the ability to adjust server configuration at runtime, and I
don't believe that it makes sense to actually bundle web connectors as
part of an application.  If nothing else, what happens if you have two
applications that are both going to run via an AJP connection on port
8009?  Which gets the connector?  What if one app deploys HTTP on 8080 and
another deploys HTTPS on 8080?  What if you have developers who prepare
applications, and administrators who do server administration?  Does it
make sense to require that admins have the skills and tools to alter the
application plans (potentially damaging the plans that just passed QA)?

	In any case, to address the compiled vs interpreted bit, if your
vision of management is that you must always edit a config file and then
run a tool on the config file to replace the old state of the server with
the new state, and the web console will always be read-only, I have to
respectfully disagree (no matter how fast the tool runs).


P.S. I think we should ultimately separate some goals from implementation 
and agree on things like "would be nice to have portable format for 
exchanging configurations, with ability to bundle one or more in a JAR and 
sign it" and "would be nice to be able to deploy connectors with apps".  
It seems to be the implications we disagree on more than the fundamental 

On Tue, 26 Jul 2005, David Jencks wrote:
> I really like this model and explanation and wonder just how soon we 
> can make it a reality.
> Last fall I thought we needed the ability to add gbeans to running 
> configurations so you could add datasources, queues, etc to the server 
> while you were getting ready to deploy an app, using an admin console 
> (in fact an earlier version of the one just donated by IBM).
> However, I think there's a better way to do this, namely, instead of 
> adding bits to the app server to make the environment ready for the 
> app, add bits of app server to the application so it brings what it 
> needs along with itself.  Right now we can do this with plain gbeans  
> in  all components (such as for security, corba, and web connectors), 
> and resource adapters in app clients.  I'm planning the ability to add 
> at least entire resource adapter configurations into other module 
> types, and considering adding the ability to deploy additional complete 
> j2ee modules just using the vendor plan.
> I can imagine a bit of a ui that analyzes the configurations present in 
> a server (i.e. a bunch of deployed configurations) and your application 
> and shows you what is unresolved in the application, and guides you 
> through either adding more prebuild configs to your server or adding 
> additional stuff into your application so everything is pre-resolved 
> before you try to deploy for the first time.
> I think with this point of view and possibly with such tools most of 
> the need to add gbeans to running configurations goes away.  As for the 
> question of changing and saving gbean attributes in a running 
> configuration, I'm not sure what to think.  It seems like an 
> interpreted vs compiled language debate.  Right now our "compiler" is 
> decidedly inconvenient for a rapid change cycle: I'm not sure how much 
> faster it would need to get before it seemed like a more reasonable 
> alternative to live changes.
> thanks
> david jencks
> On Jul 25, 2005, at 7:09 PM, Jeremy Boynes wrote:
> > I'd ask you to set aside traditional thinking and try this out for a 
> > bit.
> >
> > When you write code, you edit a couple of source files, compile it, 
> > fix the typos, build a jar, test it, decide its good enough and commit 
> > the change. After doing this a few times you decide its good enough 
> > and do a release, taking the jar file you built and saving for 
> > posterity. You then do it all over again.
> >
> > If you're doing this with Maven, it spells out the difference between 
> > the jar you are working with (a SNAPSHOT) and the jar you release 
> > (something with a version number).
> >
> > Sound familiar?
> >
> > In a large production environment you do the same kind of thing with 
> > system configurations. You set up a system the way you want, check 
> > that it works, beat the snot out of it (aka stress testing or 
> > benchmarking), see how/when it falls over, tweak the config and repeat 
> > until it you're happy, then document it, have someone else try the 
> > change in your staging environment, check it still works, then beg the 
> > change control board to let you move it to production at 3AM on a 
> > Sunday morning. You then cross your fingers and hope it really works.
> >
> > A bit different from changing things on a desktop machine or the box 
> > that runs the family website, but not unrealistic and the problem the 
> > architecture was trying to simplify.
> >
> > [[ to avoid a disgression, is Geronimo ready for this? Who knows; in 
> > the end the people doing such things factor in the risks associated 
> > with any software no matter how mature and they will make up their own 
> > minds ]]
> >
> > The idea behind the configuration bundles is that they are pre-wired 
> > sets of closely coupled components that co-ordinate to perform a 
> > specific task. A single bundle is *not* meant to represent the entire 
> > system assembly - the current o/a/g/Server is an abberation caused by 
> > problems in the classloader model (described elsewhere) not example of 
> > "best practice."
> >
> > The purpose of a bundle is to allow a knowledgable person to, for 
> > example, pre-wire a web container in a way that allows other people to 
> > use it just by defining a few characteristics. So, for example, 
> > someone can go to a repository and find, for example, a pre-wired 
> > version of a Jetty bundle pre-configured for 100 concurrent users at 
> > 95% static content with a typical dynamic reponse time of 500ms when 
> > running on an Acme-4000 Linux machine.
> >
> > So why does this need to be immutable? Because if you are pulling 
> > these things from a catalog then you need to know that you're going to 
> > get what you expect and not some version that someone happened to 
> > tweak but just forgot to change the name.
> >
> > It would be like having several jar files out there called 
> > log4j-1.2.8.jar that were actually different - a recipe for chaos. BTW 
> > one reason bundles are JAR files is because it's dead easy to sign 
> > them so that you can tell if they have been tweaked.
> >
> > Now, just as in the code development example I gave at the top, these 
> > kind of pre-packaged bundles are also going to go through a 
> > development process. One reason we didn't version stamp the configIds 
> > in the current assembly is that until now all our configurations have 
> > really been in development and it didn't make sense to be dealing with 
> > new versions all the time. It probably would have been clearer to id 
> > them as e.g. o/a/g/Server/1.0-SNAPSHOT but I guess that's water under 
> > the bridge now.
> >
> > So, in an ideal world, your user below would just pick a suitable 
> > pre-built bundle out of some repo and be happy with what it does. If 
> > it doesn't quite do what they want or nothing suitable can be found, 
> > they start by building and tweaking my/web/Container/1.0-SNAPSHOT, 
> > iterate it a few times and then finalize on my/web/Container/1.0.
> >
> > The problem is identical to a developer not filling up their Maven 
> > repo with trivially different versions of a jar they are working on 
> > (which is why Maven has SNAPSHOTs in the first place).
> >
> > To pick a bad analogy, we're trying to do with server configuration 
> > what Maven did for builds. No, I don't mean trying to make it slow and 
> > take forever to start. We're trying to simplify the administration 
> > process by allowing a admin to choose from a re-usable set of 
> > pre-optimized bundles rather than having to do it all by hand, in the 
> > same way Maven uses plugins to replace manually created ant scripts.
> >
> > It's different. It's unusual. It takes some getting used to.
> > But it might just work.
> >
> > --
> > Jeremy
> >
> > 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
> >>>
> >

View raw message