[
https://jira.jboss.org/jira/browse/TEIID-600?page=com.atlassian.jira.plug...
]
Steven Hawkins resolved TEIID-600.
----------------------------------
Resolution: Done
This fix now unifies connector/extension loading for both embedded and server. A full
description of embedded classloading is:
App ClassLoader - Possibly from a container loads the client jar
Lib ClassLoader - loads all applicable entries from lib/patches in the embedded install
Post delegating lib override ClassLoader - from TEIID-590 prevents version conflicts
between our lib and the lib's parent
Common extension ClassLoader - A shared classloader initialized from the common
extension property (TEIID-418). Connector and other dependencies are added dynamically as
need. Extension module changes trigger a reload of this shared class loader.
Post delegating Connector ClassLoader - optionally created if the connector
property UsePostDelegation is set to true, then the connector classpath and connector type
classpath entries are loaded in their own classloader (which can also be cached).
The only connectors that set UsePostDelegation to true are xml and salesforce. All of the
others are allowed to add their dependencies at runtime into the shared common extension
classloader. The advantages of this approach:
- Allows connectors to optionally use a delegating classloader in an efficient manner.
This fixes the issue observed with the oracle driver - of course the user can still put
their dependencies in the lib if desired.
- Does not require any changes to the Designer.
- Is the same for embedded/server
Connector developers must still be cautious - if a custom connector introduces a
conflicting dependency then it must have the UsePostDelegation flag set to true. In the
rare case of a post delegating connector that also has a dependency that needs to be
delegating, then the entry must be removed from the appropriate connector classpath and
manually added to the common extension classpath property.
Better handling of connector depdendencies
------------------------------------------
Key: TEIID-600
URL:
https://jira.jboss.org/jira/browse/TEIID-600
Project: Teiid
Issue Type: Quality Risk
Components: Connector API
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 6.1.0
Connector dependencies by in large really fall into two categories - our built-in jars or
jars that are intended to be at a system level (such as a driver). By only allowing these
jars to exist under a post delegation class loader there are many downsides - it has a
negative impact on memory, it can cause issues with classloader leaks, makes built in
connector patching more difficult, and simply won't work in the case of native oracle
drivers. Here are the steps we would like to take to address this:
Promote all top-level built-in connector jars to the lib - this would be things like
connector-jdbc, connector-ldap, etc.
Add the notion of the common extension classpath to the dqp.
Change the common extension classpath to be a delegating classloader.
Change the meaning of the connector classpath to "required common
dependencies", then at the start of any connector service ensure/add all entries from
the connector classpath into the common extension classpath. The common extension
classpath will be cached and managed similar to the connector classloader cache. Changes
to extension modules will cause it to be reloaded. Since this approach does not actually
threat connector classpath setting as a classpath ordering of the entries doe not matter
and thus patch jars would not be useful in this setting. Rather users would simply
replace the extension module they are attempting to patch.
The connector type classpath would remain and still specifies required post delegation
libraries.
How Designer is managing dependencies does not need to initially change at all.
Basically all jars added as connector dependencies will be treated as common. The only
scenario that won't work initially is a custom connector requiring post-delegation
libraries. We can address this at a later time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira