Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <428A763E.1070405@apache.org>
Date: Tue, 17 May 2005 15:54:54 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: API and serialization compatibility, was: Build Failure
References: 
 <OFC84B06EB.FCAF0409-ON80257001.006EAD41-80257001.006F184B@uk.ibm.com>
 <530E1479-FF80-4059-8FA5-ABC00E41E382@iq80.com> <42868212.5010904@apache.org>
 <20050516155937.GD16149@django>
In-Reply-To: <20050516155937.GD16149@django>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Blevins wrote:
> On Sat, May 14, 2005 at 03:56:18PM -0700, Jeremy Boynes wrote:
> 
>> And after all, one requirement Sun place on a JavaBean is that it
>> is Serializable.
>> 
> 
> 
> They do not require that the JavaBean is serializable bewteen
> versions of the class.  That requirement and the problems it
> introduces are Geronimo's.
> 

The serialization contract goes into a lot of discussion on object 
versioning, compatible and incompatible changes, and how the class is 
responsible for maintaining that contract. A lot of the details are here:

http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/serialTOC.doc.html

The requirement from Geronimo's side is that the attributes are 
persistable. We originally chose Serialization for that because:
* it is simple to implement
* the mechanisms for managing version skew are clearly defined

We could have chosen XML JavaBean persistence; it was rejected because:
* it requires the attributes to be JavaBeans (serialization does not
   impose any such requirement)
* the persistence mechanism operates via the public API. This means
   the beans would have to expose all internal attributes through
   their public API even if they were not part of the general contract.
   This would make it harder to adapt non-Geronimo objects as it may
   involve extending the public API
* the XML form does not contain any semantic meaning pertaining to
   the class being persisted. It is a generic schema applicable to
   any JavaBean and not validatable against the objects being stored.
* The XML form is human editable but ugly and unvalidatable leading
   to a much higher risk of error compared to serialization (which is
   uneditable) or true XML persistence

We could also have chosen alternative XML persistence e.g. JAXB, Castor, 
XMLBeans, (insert framework here). This was rejected because:
* The framework would be needed at runtime and none of them are small.
   This would lead to problems trying to run Geronimo on small
   footprint devices.
* Again, the framework operates via the public API forcing objects to
   expose all attributes through it


Having said that, it is also worth taking note of David Jencks's 
comments that Serialization only applies to GBean attribute values and 
not to the implementation classes or to references between GBeans.

As he pointed out with ActiveMQ, problems appear to be occuring not 
because the attribute values are not serializable but because what 
attributes are present is incompatibly changing. This would occur with 
any of the mechanisms above.

--
Jeremy