Persistency problem

M

Mauro

Hi All,
I have a problem that I believe is quite common, but I've been unable
to find satisfactory solutions.

Problem is model persistence: I have a fairly complex model that my
application edits using the normal MVC pattern.
The model is roughly tree-like with a series of Nodes, Lists and Leafs
(I can get into details, but it seems useless at this point). The only
thing I think may be relevant is the
class hierarchy:

public interface ChangeEmitter
public interface IOCElement extends Serializable, ChangeEmitter
public abstract class AbstractIOCLeaf implements IOCElement
public abstract class AbstractIOCNode extends AbstractIOCLeaf
implements ChangeListener
public abstract class AbstractIOCList<T extends IOCElement>
extends AbstractIOCNode implements ComboBoxModel

All the classes composing my model extend one of the three abstract
classes.
In particular the current root of the model is:

public class IOController extends AbstractIOCNode {
protected EventList el = null;
protected TaskList tl = null;

where, quite predictably, public class TaskList extends
AbstractIOCList<Task>, ...

The editing is somewhat limited: The user cannot change tree topology,
he can only add/remove entries to the lists and set (some) Leaf
properties.
On the other hand I, as application developer, *will* change (mostly
adding features) alter the tree topology.

I need to save this model to some on-disk structure and read it back.

Current solution is use writeObject: it works, but it is
unsatisfactory because it is not resilient enough to tree topology
changes.

I tried using XMLEncoder, but I must be missing some fairly important
detail, because it produces an empty XML (just the name of the root
class, sometimes with a single property... always the same, if
present... that is declared "transient" in abstractIOCLeaf !!). I can
make XMLEncoder work on simple test cases, but in the "real-life"
program it silently fails.

Real question is:
Can someone help me to understand why XMLEncoder fails miserably
(while writeObject works, within its limits)?

Alternatively: Are there other fairly solid alternatives to implement
persistency I should explore? I already spent in this apparently
trivial task a lot of time.

Thanks in advance to anyone!
Mauro
 
T

Tom Hawtin

Mauro said:
I tried using XMLEncoder, but I must be missing some fairly important
detail, because it produces an empty XML (just the name of the root
class, sometimes with a single property... always the same, if
present... that is declared "transient" in abstractIOCLeaf !!). I can
make XMLEncoder work on simple test cases, but in the "real-life"
program it silently fails.

XMLEncoder serialises public bean properties. It appears to run into
trouble on anything non-trivial (look at the source and the hard-coded
logic to serialise AWT and Swing beans).

For java.io.Serializable, you need to design your serial interface as
much as you design your programming interface.

Tom Hawtin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,007
Latest member
obedient dusk

Latest Threads

Top