For background, see the post to the mailing list.

Injection approach

The injection approach is working. At least, it's not crashing.

PROS

• simple
• no constraints on the object injected
• injects the real object
• makes clear the mapping of the value to its target(s)

CONS

• injects only into a property (for now)

Dynamic proxy approach

I thought I had it working. It works fine for JButton object but not for BrowseWeb objects (the next one I tried).

PROS

• completely transparent to the code
• great flexibility in time of object acquisition

CONS

• proxy is an Object
• it can only be cast to an Interface
• the set of Interfaces a proxy implements must come from the same classloader
• I can't figure out why it fails for BrowseWeb

Revised injection plan

This came out of today's meeting. It consists of two key changes from the injection plan above.

1. constrain pod references to children of the pod
2. set of imports in addition to exports
3. override writeObject of XMLEncoder

Constrain pod references to children of the pod

Consider podA which uses podB.export0 while podB uses podA.export0. The only way to reconstruct this safely is to instantiate all the objects in one pass, and then link them all in a second pass. This requires that after all the objects are instantiated there is some means of filling in the links. This is extremely difficult to do with any flexibility of link target.

Instead, let podC dictate that some slot in podA take podB.export0 and some slot in podB takes podA.export0. Then we have a poset: {podA < podC, podB < podC}. In other words, podA and podB can be constructed in parallel but have to be completed before podC is constructed. This means that the injection can take place during the construction of podC since it can rely on the source values being already constructed in podA and podB.

Put even more simply, we construct the pod tree bottom-up.

Set of imports per pod

Pods already register the values they export. Now they also register the values they import. This is accomplished by

registerImport(String name, Object invocationTarget,
			Method invocationMethod)}}

See sail.core.ImportTest for a demo of how it's used and continues to work after unmarshalling.

So now we have a podLinks property, piping exports to imports. Do we keep the injectionMap property for the lighter case of a parent pod consuming an export of a child? The parent shouldn't have to register an import in order to set that value, right?

override writeObject of XMLEncoder

I thought this was necessary but that was before I implemented imports. Is it really necessary anymore?

Challenges

Reverse any assembly at disassembly time

The assemblyCalls set of calls allows pretty much arbitrary execution of code. While that's neat, it makes undoing those calls impossible. We can't save the state of everything before changing it. We could have a disassemblyCalls that the authoring tool is responsible for filling when it adds to assemblyCalls, but that's too complicated for the cases we have so far. We really can restrict ourselves to property names, which reveals the setter, getter and default value.

Fill a slot with local objects and imported ones

The reason I went with Methods over property names is I wanted to be able to fill in values that weren't properties. Specifically, adding to the list of activities in a project. I made it work with an addActivity() method call but that's a one-way street. We need to to figure out a way to
make the activity list reference activities both within the pod and in its children pods.

Perhaps it's a special case and we create a new type of property MixedList or something. It is responsible for keeping track of what's an object reference and what's imported. Its PersistenceDelegate can write out what's right.

Context

One problem is that when writing an object, we don't know whether it's being written within its home pod or within the context of a pod that imported it. java.beans.XMLEncoder doesn't appear to provide any way of knowing this. Hmm, wait, what about owner? We can check to see if the owner (Pod) imports the value (from the import table) and if so skip it. Genius. I hope it works, I'll try it.

Otherwise, we can try switching to XStream and using MarshallContext.