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
