Coupling between namespace object models

[starksm64]

I'm looking at the org.jboss.test.xml.MultispacedUnitTestCase which demonstrates unmarshalling a document that has two schemas/namespaces for two object models that are loosely coupled via a one-one unidirectional relationship. The two object models are the XMBeanMetaData and JDBCPm. A XMBeanMetaData can contain a JDBCPm, but the coupling in terms of type is that the XMBeanMetaData.persistenceManager is just an Object.

Now what I see in the XMBeanMetaDataFactory which knows how to unmarshall XMBeanMetaData instances from xml and the JDBCPmMetaDataFactory which knows how to unmarshall JDBCPm instances from xml, that the JDBCPmMetaDataFactory has an explicit type coupling to the particular usage context of an XMBeanMetaData containing a JDBCPm. This shows up in the following JDBCPmMetaDataFactory method:

 public void addChild(XMBeanMetaData xmbean,
 JDBCPm pm,
 ContentNavigator navigator,
 String namespaceURI,
 String localName)
 {
 xmbean.setPersistenceManager(pm);
 }

This should really be the other way around. The XMBeanMetaDataFactory knows that is supports a persistence element of type="xs:anyType" as the injection point for the persistenceManager. So, the XMBeanMetaDataFactory is the factory which should have binding method:

 public void bind(XMBeanMetaData xmbean,
 Object pm,
 ContentNavigator navigator,
 String namespaceURI,
 String localName)
 {
 xmbean.setPersistenceManager(pm);
 }

This way, all ObjectModelFactory implementations deal with only the object models they understand. As the example currently exists, the JDBCPmMetaDataFactory has to know about every context in which its used.

Would this be a difficult change to make?

[aloubyansky]

This is a good point.
This issue also raised a few others in my mind regarding this type of object model factories, i.e. the one that uses introspection when adding children to parents.

If you look at the factory implementation, you will see that all addChild methods are 'typed', i.e. parent and child are of concrete Java types. So, as it works today, you would have to move that addChild method you are talking about from JDBCPmMetaDataFactory to XMBeanMetaDataFactory. Which is not really good, since the parent and child are still typed. And XMBean might have some other non-JDBCPm persistence manager.

I'll work on the fix and let you know.

[starksm64]

Correct, the type binding can only be as strong as the object model itself exposes. The xml framework should not be looking for more explicit type bindings by default. That should not preclude an object factory from choosing to expose type specific injection points, so say the xmbean factory wants to maninpulate the JDBCPm and FilePm prior to establishing the relationship:

 public void addChild(XMBeanMetaData xmbean, JDBCPm pm,
 ContentNavigator navigator, String namespaceURI, String localName)
 {
 pm.x(...);
 xmbean.setPersistenceManager(pm);
 }
 public void addChild(XMBeanMetaData xmbean, FilePm pm,
 ContentNavigator navigator, String namespaceURI, String localName)
 {
 pm.y(...);
 xmbean.setPersistenceManager(pm);
 }
 public void addChild(XMBeanMetaData xmbean, Object pm,
 ContentNavigator navigator, String namespaceURI, String localName)
 {
 xmbean.setPersistenceManager(pm);
 }

Sure this is just a convience for doing type chekcs in the most generic signature, but if its not a big deal to implement its cleaner.

[aloubyansky]

This is exactly how I am going to fix this.

Also there already is GenericObjectModelFactory interface. Which accepts parents and children as java.lang.Object's. Implementations of this interface are not introspected for 'typed' methods. So, everything is delegated to generic methods.

[aloubyansky]

Decoupling phase is done. The testcase is updated. Now, the 'property type' phase...

[aloubyansky]

It's done.