TCCL expectations

[Steven Hawkins]

What expectations are there for the thread context classloader with LocalManagedConnectionFactory?  I see in the LocalManagedConnectionFactory source that the context classloader is set when getting the driver/datasource, but not for any other interaction.  We're seeing a class not found issue on the driver connect call as the context classloader is no longer set to the classloader of the resource adapter - https://issues.jboss.org/browse/TEIID-4617 which is an issue with the Mondrian 3.6+ driver.  

Is it possible to have all calls into the driver/datasource with the thread context classloader set to the classloader of the resource adapter?

Thanks,

Steve

[Lin Gao]

IMO, in WildFly, the ClassLoader used to get database connection is either the module class loader where the jdbc driver is located or the module class loader where the data source is defined[1].

[1] https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/subsystems/datasources/AbstractDataSourceService.java#L306

[Steven Hawkins]

I'm specifically concerned about the thread context classloader for the Driver.connect call in https://github.com/oloake/IronJacamar/blob/master/adapters/src/main/java/org/jboss/jca/adapters/jdbc/local/LocalManagedConnectionFactory.java#L249

Note that LocalManagedConnectionFactory sets the thread context classloader when creating the driver/datasource https://github.com/oloake/IronJacamar/blob/master/adapters/src/main/java/org/jboss/jca/adapters/jdbc/local/LocalManagedConnectionFactory.java#L620, but not when connecting.

[Lin Gao]

Dear Steven,

  What version of IronJacamar do you use? I can not find the method: 'isDriverLoadedForURL' displayed in the second link in any active branch of IronJacamar: 1.0, 1.2, 1.3 and 1.4

  Or if you use WildFly as the base foundation, what version of WildFly do you use, so that I can see which IronJacamar it actually uses for your problem. :)

  There is a method call: 'Thread.currentThread().setContextClassLoader()' in your second link before loading the JDBC driver class, but it sets the current thread context class loader back in the final block too.

  IMO, the root cause for the TEIID-4617 is that the driver.connect() in Mondrian depends on the thread context class loader (which may be null), it may need to try to use the current class loader too if the class can not be found in the current thread context class loader.

Best Regards

[Steven Hawkins]

Sorry if the link was incorrect.  We are using WildFly/EAP.  TEIID-4617 was logged against EAP 6.4, but the issue is present in WildFly 10 with ironjacamar-jdbc 1.3.2

> There is a method call: 'Thread.currentThread().setContextClassLoader()' in your second link before loading the JDBC driver class, but it sets the current thread context class loader back in the final block too.

That is correct.  What I'm asking is if that behavior of setting the thread context classloader can be used for the other interactions with the driver/datasource.

>  IMO, the root cause for the TEIID-4617 is that the driver.connect() in Mondrian depends on the thread context class loader (which may be null), it may need to try to use the current class loader too if the class can not be found in the current thread context class loader.

As you can see on the Teiid issue, we've reached out to the Mondrian community as well - http://forums.pentaho.com/showthread.php?215863-Classloading-issues-with-Mondrian-driver-on-WildFly-10

From a Teiid community perspective a change in either the driver or the JCA layer.  So we're open to which ever community can work with us.

[Lin Gao]

On Tuesday, December 13, 2016 at 10:49:21 PM UTC+8, Steven Hawkins wrote:

Sorry if the link was incorrect.  We are using WildFly/EAP.  TEIID-4617 was logged against EAP 6.4, but the issue is present in WildFly 10 with ironjacamar-jdbc 1.3.2

> There is a method call: 'Thread.currentThread().setContextClassLoader()' in your second link before loading the JDBC driver class, but it sets the current thread context class loader back in the final block too.

That is correct.  What I'm asking is if that behavior of setting the thread context classloader can be used for the other interactions with the driver/datasource.

I think there are no explicit requirements on the thread context classloader when java.sql.Driver.connect() method is called, setting it to the defining classloader of the current class or null may solve this specific Mondrian case, but it may lead to possible regressions on other drivers.

On the other hand, I think Mondrian made the wrong assumption that the classes it wants to load are in the thread context classloader.

So for this issue, it is better to wait for Mondrian fix. :)

Best Regards