From dev-return-12464-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Sun May 15 00:50:04 2005
Return-Path:
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 5843 invoked from network); 15 May 2005 00:50:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
by minotaur.apache.org with SMTP; 15 May 2005 00:50:03 -0000
Received: (qmail 40960 invoked by uid 500); 15 May 2005 00:54:21 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 40591 invoked by uid 500); 15 May 2005 00:54:19 -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 40568 invoked by uid 99); 15 May 2005 00:54:19 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from Unknown (HELO mgd.gluecode.com) (64.14.202.141)
by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 14 May 2005 17:54:18 -0700
Received: from [192.168.15.108] (69-175-254-134.vnnyca.adelphia.net [69.175.254.134])
(authenticated bits=0)
by mgd.gluecode.com (8.12.10/8.12.10) with ESMTP id j4F0nLCW021775
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO)
for ; Sat, 14 May 2005 17:49:25 -0700
Mime-Version: 1.0 (Apple Message framework v728)
In-Reply-To: <42868212.5010904@apache.org>
References: <530E1479-FF80-4059-8FA5-ABC00E41E382@iq80.com> <42868212.5010904@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom
Subject: Re: API and serialization compatibility, was: Build Failure
Date: Sat, 14 May 2005 17:49:42 -0700
To: dev@geronimo.apache.org
X-Mailer: Apple Mail (2.728)
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N
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