Ugliness. I don't suppose it's possible that we use the 'patch.jar'
classpath entry to create a default place to add extensions and patches for the
----- "Steven Hawkins" <shawkins(a)redhat.com> wrote:
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
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
It doesn't seem that there is a simple answer to this problem.
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 rar.
2. Investigate OSGI support
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.
teiid-users mailing list