Custom Connector Development With JCA

[shawkins]

I'm moving this discussion from the mailing list to the forum to keep it a little more persistent.  From the post:

With the JCA work, the current rar packaging for connectors presents a few issues with the old way we used to manage dependencies.  For example if I want a custom JDBC connection which introduces a new connector binding property and custom code, then I would need to create a copy of the jdbc rar, add my custom jar, and modify the ra.xml file.  Since the jdbc rar contains our jdbc connector jar, now there are two copies of that jar.  Management of patching becomes an issue.

Even in a simpler case which is providing my own implementation of capabilities of the Translator class would require either that I place my custom code in a higher level class loader or create a copied rar and add my custom jar.  In the former case there is the possibility of class loading issues, in the latter there's the same duplicated dependency issue.

It doesn't seem that there is a simple answer to this problem.  Options include:

1. Elevating all of the built-in connector jars to the same class loader as the connector api.  Now there is a single place to manage/patch the dependency.  This path assumes that the xml connectors will be refactored to contain only minimal external dependencies, otherwise they would still need to be managed as rars.

2. Investigate OSGI support (http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html) so that we can use declared dependencies.  However this is a poor fit with the JCA model and adds additional complexities.

3. Treat all custom connector work, even extensions of our connectors, equally.  Each new type requires a rar and any dependency maintenance becomes the responsibility of the customer.

4. Deploy our rars as an exploded directory.  Custom classes can be placed inside the rar structure.  This however does not address custom connector properties or isolating versions of the custom connector code.

[jdoyle]

I'm not a fan of option #1.  The problem with 'the minimum' is that there's still guarantee that the minimum won't cause problems.  We saw this recently with the commons-logging.  Were we to go this route I thing we need to be specific about what's in the classpath that the connector writer gets.  #2 seems too complicated to me.  Of these I guess I prefer #3.

~jd

[shawkins]

The new split between translator and resource adapter logic ensures that custom development intended to extend our functionality will just utilize our translator jars (of which there will only be a single copy) and/or would be entirely new JCA development, which would be completely independent of Teiid.

The only issues remaining are about dependency management.  If a custom translator extension is introduced for examle, it would be placed with the teiid deployer or the lib, which implies that we only support a single version.