From dev-return-12451-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sat May 14 16:47:42 2005 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 88400 invoked from network); 14 May 2005 16:47:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 May 2005 16:47:42 -0000 Received: (qmail 35188 invoked by uid 500); 14 May 2005 16:52:05 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 35106 invoked by uid 500); 14 May 2005 16:52:05 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 35089 invoked by uid 99); 14 May 2005 16:52:04 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from adsl-209-233-18-245.dsl.snfc21.pacbell.net (HELO buttons.boynes.com) (209.233.18.245) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 14 May 2005 09:52:04 -0700 Received: from [127.0.0.1] (unknown [192.168.37.171]) by buttons.boynes.com (Postfix) with ESMTP id 7B56A14448 for ; Sat, 14 May 2005 09:47:34 -0700 (PDT) Message-ID: <42862BA3.7080902@apache.org> Date: Sat, 14 May 2005 09:47:31 -0700 From: Jeremy Boynes User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: API and serialization compatibility, was: Build Failure References: <42852818.2080904@apache.org> <42852D72.7000405@apache.org> <20050513225404.GB13354@django> In-Reply-To: <20050513225404.GB13354@django> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. -- Jeremy