geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: API and serialization compatibility, was: Build Failure
Date Sun, 15 May 2005 00:49:42 GMT
On May 14, 2005, at 3:56 PM, Jeremy Boynes wrote:

> Dain Sundstrom wrote:
>
>> Tim,
>> As you point out, the problem of serialization is far reaching.    
>> Basically, we need to get every project included in Geronimo to  
>> buy  into serialization stability, and to my knowledge there are  
>> no  projects in Geronimo that today have committed to this.  In  
>> addition,  Geronimo itself is does not support serialization  
>> stability, and if  we choose this path, we must clean up our own  
>> house by verifying  every serializable class is set up for upward  
>> compatible  serialization.  This is by no means an easy task, but  
>> I think before  we ask something of other project we are aware of  
>> the effort involved  in what we are asking.
>> Alternatively, we could choose to do like Sun did with swing and  
>> give  up on serialization and use an xml based storage mechanism  
>> based on  Java Beans rules.
>>
>
> The issue is not the implementation (serialization vs. XML) but the  
> compatibility of the information set between versions.

Actually implementation IS the issue.  If we choose serialization,  
the other projects must agree to implement Serialzable and maintain  
upward compatibility.  If we choose an xml strategy like Sun's  
JavaBeans xml stuff, the other projects must only agree to maintain  
compatibility of public property names (i.e., the getter and setter  
names not the private field names) and constructor arguments.  This  
is much smaller task to ask of other projects, since most are already  
providing IoC compatible services.

> As David Jencks has pointed out elsewhere, we do not need every  
> project to commit to serialization stability everywhere, just in  
> the classes that are being used in GBean attributes. If they do  
> great; if they don't we just don't use those classes as attribute  
> values and handle reconstruction ourselves.

I agree with the statement, but we have only pushed the problem down  
one level.  For example if we have the following bean in geronimo:

public class Person {
   private final String name;
   private final int age;
   private final Car car;
   private final Address address;

   public Person(String name, int age, Car car,  Address address) {
       ....
   }
}

The Person class does not need to be serializable, because Geronimo  
only serializes the class name and attribute values.  The attributes  
themselves must be either serializable of be a service reference in  
geronimo.  This is not a problem for most services written by  
Geronimo but for services from other projects this is a huge issue.   
Many projects do not initialize services with simple data types, but  
instead use complex configuration object that are not serializable  
stable.

In the end we have not solved the problem.  We have only pushed the  
problem down one level from the service to the service attributes.

-dain


Mime
View raw message