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: API and serialization compatibility, was: Build Failure
Date Sat, 14 May 2005 19:45:28 GMT
	Okay, well, as long as we've opened this can of worms...

	Jeremy, what is your intention WRT editing configurations without
the server running?  For example, let's say you do a default install, but
do not start the server.  Now you start a different product that binds to
port 8080.

	At this point, I think you'll be unable to start Geronimo due to 
the port conflict (assuming that J2EE services are enabled).  You're also 
unable to change the Jetty port without re-installing, and then only if 
you use the installer rather than a ZIP distribution.  Needless to say, 
and web-based configuration or management system is also inaccessible.

	This certainly seems like a good case for XML based configuration
state, where you could trivially edit a config file to change the Jetty
port and *then* start the server.  But it's not the only option.  Do you
have a vision for some kind of tool that would let you change the server
configuration while it is not running?  Perhaps something that will let
you deserialize and edit arbitrary configurations?

	I'm also assuming that the end user does not have access to (or 
substantial knowledge of) the plans used to construct the server in the 
first place.

Aaron

P.S. I also feel that it would be unfortunate if the kernel APIs changed 
across bug-fix releases.  So I'm happy to try to freeze those.

On Sat, 14 May 2005, Jeremy Boynes wrote:
> David Blevins wrote:
> > On Fri, May 13, 2005 at 03:42:58PM -0700, Jeremy Boynes wrote:
> >> Solving the compatibility problem will require the developers to
> >> pay attention to versioning. We will need to require that at some
> >> point though.
> > 
> > 
> > Paying attention is an understatement.  In order to serialize data to
> > and from class definitions, those classes cannot change in any
> > significant way, ever.  No refactoring, repackaging, reorganizing, no
> > removing methods, no removing class variables.  This doesn't just
> > apply to public APIs, but even the internal classes of each
> > component.
> > 
> 
> In other words, the level of stability users expect from 
> enterprise-grade software.
> 
> <snip/>
> > 
> > Serializing and deserializing server state for fast startup is a cool
> > feature, but not something we are in any position to guarantee
> > between releases of Axis, ActiveMQ, OpenEJB, Jetty, Tomcat, et. al.
> > 
> 
> True, but the configuration management archtecture in Geronimo is 
> designed to handle this. The main principle behind it is that the 
> bundles being run are, to the largest extent possible, pre-built and 
> ready to go. There are two things in play here - the code and the data.
> 
> For the code, each configuration defines precisely the codebase it uses. 
> Right now, it uses the *UNIQUE* id of its parent config plus the 
> *UNIQUE* version numbers of its repository dependenies.
> 
> The emphasis on *UNIQUE* is critical - it means the version of code that 
> the configuration uses (both internal and external) is known precisely. 
> That means we can guarantee that the the configuration state can be 
> restored. How that it is done is a matter of implementation; we use 
> serialization because it is fast and requires less infrastructure but we 
> could just have easily used XML. The data versioning problem applies 
> equally to both. In other words, we don't use serialization just to get 
> fast startup, we use it because it is an effective way to store 
> configuration state.
> 
> 
> Right now we have a very restrictive model where we only allow exact 
> matching of codebase versions. This works well in a development 
> environment where a lot of things are changing and being rebuilt all the 
> time for but production rollout we always knew that this would need to 
> be enhanced to support looser binding (the so-called 'capabilities model').
> 
> With that in place, the builders can choose how tightly the bind the 
> generated configuration to the runtime environment. For some components 
> they may still choose to bind precisely, perhaps because there is some 
> implementation issue, or perhaps because the component itself handles 
> skewed versions. For other components, it might specify a looser binding 
> letting the runtime configuration management system choose which 
> implementation to use.
> 
> 
> Another thing to remember is that the only classes where serialization 
> compatibility really matters are those that are actually placed in 
> persistent attributes. I would hope all the projects we use do support 
> serialization properly, including providing UIDs and dealing with 
> version drift; if not we should encourage them to do so and help where 
> necessary - it is generally a /good thing/. That will make configuration 
> management easier for both system administrators as well as the runtime 
> and deployment systems.
> 
> 
> Coming back to the original issue though, there are some places where 
> all the configuration management magic in the world can't help - 
> specifically in the kernel and in the configuration management system 
> itself. It is critical that the APIs and implementations there are 
> stable and that they support serialization properly.
> 
> --
> Jeremy
> 
> 

Mime
View raw message