org.sonar.batch.bootstrap
Class JdbcDriverHolder

java.lang.Object
  org.sonar.batch.bootstrap.JdbcDriverHolder

public class JdbcDriverHolder
extends Object

Contains and provides class loader extended with the JDBC Driver hosted on the server-side.

Constructor Summary

JdbcDriverHolder(FileCache fileCache, AnalysisMode analysisMode, ServerClient serverClient)

Method Summary

void	start()
void	stop() This method automatically invoked by PicoContainer and unregisters JDBC drivers, which were forgotten.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

JdbcDriverHolder

public JdbcDriverHolder(FileCache fileCache,
                        AnalysisMode analysisMode,
                        ServerClient serverClient)

Method Detail

start

public void start()

stop

public void stop()

This method automatically invoked by PicoContainer and unregisters JDBC drivers, which were forgotten.

Dynamically loaded JDBC drivers can not be simply used and this is a well known problem of DriverManager, so workaround is to use proxy. However DriverManager also contains memory leak, thus not only proxy, but also original driver must be unregistered, otherwise our class loader would be kept in memory.

This operation contains unnecessary complexity because:

• DriverManager checks the class loader of the calling class. Thus we can't simply ask it about deregistration.
• We can't use reflection against DriverManager, since it would create a dependency on DriverManager implementation, which can be changed (like it was done - compare Java 1.5 and 1.6).
• So we use companion - JdbcLeakPrevention. But we can't just create an instance, since it will be loaded by parent class loader and again will not pass DriverManager's check. So, we load the bytes via our parent class loader, but define the class with this class loader thus JdbcLeakPrevention looks like our class to the DriverManager.