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.
Surely if a project is not prepared to maintain compatibility for Serializable objects it is not going to maintain property compatibility either. In fact, given the flexibility of the JavaBean model (well not strictly as JavaBeans are meant to be Serializable) and the lack of any indication of persistence (e.g. that it does not implement a tag interface or have a marking annotation) I would argue that property drift was more likely as there would not be anything to indicate to a developer that compatibility would be required.
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.
Indeed, but pushing it down that level is critical as it lets the GBean implementation handle the reconstruction of the underlying object graph.
Most simple attributes have Serializable values. No problem.
Any project that tags its classes as Serializable ought to handle the version drift. If it indeed does so, no problem. If it does not, then we simply treat the values as if they were non-Serializable.
If the values are non-Serializable then the project needs to define how the objects can be persisted; hopefully that includes a way to handle version drift. The GBean can use that mechanism to convert the non-Serializable object graph to/from its persistent form stored in a Serializable object such as a byte[] or char[]
Let's be clear, there are several issues here: 1) persistent form. Serialization provides a very low-overhead, high- performance solution and can be used to underpin higher level abstractions.
2) object version skew. Again Serialization provides clearly documented ways to handle that.
3) adoption. Serialization is easy to implement especially for mature objects with little version skew. XML JavaBean persistence is not widely used as the external XML format is not designed for human modification. XML in conjuction with a persistence schema is more widely used but carries high overhead especially when schema validation is used.
4) configuration version skew. This is handled by the configuration management system as discussed elsewhere.
The current model provides a very effective, high-performance, low-overhead configuration persistence mechanism that can be extended with higher level mechanisms where appropriate.
-- Jeremy
