geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: API and serialization compatibility, was: Build Failure
Date Sat, 14 May 2005 16:47:31 GMT
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.

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


View raw message