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 21:18:36 GMT
	FYI, I'm considering this a discussion on our long-term policy.  
In the immediate future, I'm planning to go ahead with mutable
configurations to support the desired functionality in the web console.  
I'm definitely open to revising that when the time comes and we have a
more comprehensive strategy around this.


On Tue, 26 Jul 2005, Jeremy Boynes wrote:
> Aaron Mulder wrote:
> > 	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
> > content.
> > 
> You alude to the problem yourself without realizing it. We have an 
> example of the problem right now with our build system and its use of 
> SNAPSHOT jars.
> SNAPSHOTs are mutable. Their content varies over time based on whatever 
> happened to be in the source tree when they were built. If you have a 
> SNAPSHOT artifactId you won't know from one build to another that you 
> are using the same code.
> To the person developing that artifact, that it is a SNAPSHOT doesn't 
> matter - it's output work product to them, what they are using is the 
> source tree.
> However, to the person using the library it does matter. If they rely on 
> a SNAPSHOT published to a repo they can't rely on getting the same code 
> each time. If they need stability they need to use an explicit version. 
> If the publisher publishes two different codebases under the same 
> version number then, to use your phrasing, "they're an idiot" and as a 
> user you start looking for alternatives. In other words, you want 
> released artifacts to be immutable and versioned.
> To have a consistent release we can't use mutable SNAPSHOTS and we 
> (primarily John) are going through and replacing them with immutable 
> versions.
> Putting this in the configuration context, when you start modifying a 
> configuration you are "developing" it - you're tweaking it to do what 
> you want. This is not a problem for you. However, it is a problem for 
> things that "use" that configuration and have certain expectations on 
> its behaviour as it is now doing what you want and not what it 
> advertised that it could do.
> There are things in the system that "use" your configuration - the 
> config builders and the applications that they build are two examples. 
> If you mutate the Server configuration from using Jetty to using Tomcat, 
> an application that was built against that configuration with the 
> assumption that it was Jetty will no longer work.
> The HTTP connector example we are so fond of is a bad one as nothing 
> "uses" that bundle - it is a user of other bundles, dispatching requests 
> to them but nothing actually references it. You can mutate it to your 
> heart's content and nothing will notice.
> As an alternative, consider an example where an application contains a 
> message-link that uses a queue. The application builder can look at the 
> server configuration, see that there is no queue there and decide that 
> it should define one in the application bundle. That bundle can be moved 
> to any instance running that server configuration and will run quite 
> happily as it is taking its queue along with it. However, if the server 
> configuration is mutated on some instances so that it has a queue you 
> now have a conflict: two queues, one from the mutated server, one from 
> the application. Or if the configuration is mutated to use a different 
> message provider then it may not work at all.
> The challenge we face is finding a balance between the things that can 
> mutate that no-one will notice and things that should be immutable so 
> that they can reliably be used by others.
> --
> Jeremy

View raw message