5 Replies Latest reply on May 11, 2006 11:24 AM by esword

    Possible fix for driver class loading issue in LocalManagedC

    esword Newbie

      I am trying to deploy a fully isolated ear (i.e. all jars that I use are in the ear; no leaking of jars into the main lib directory). However, the app uses a couple of datasource connections, and I am hitting a problem encountered by others over the years. It is best summarized in Jira issue JBAS-1042. The issue is the same in JBoss 4.0.3SP1, which is what I am using.

      I figured out that the exception caused by the strange class loading behavior in DriverManager.getDriver() is actually only thrown the first time you try to access the driver. This is because once the driver is set in LocalManagedConnectionFactory.getDriver() by line 277:

      driver = (Driver)clazz.newInstance();

      it is never cleared. So even though an exception is thrown the first time through because isDriverLoadedForURL(url) always returns false, the check for (driver!=null) at the start of the LocalManagedConnectionFactory.getDriver() will return the driver for all future uses.

      It seems like the method should be changed in one of two ways:
      1) Change line 277 to set a local Driver variable rather than the object member variable. That way the member variable is only set by the isDriverLoadedForURL check and it will always fail (thus enforcing always going through the DriverManager). Or,

      2) (My preferred change) After the 3rd call to isDriverLoadedForURL, check if driver != null and, if so, do what DriverManager does and call driver.acceptsURL(url). That way, the (erroneous) exception won't be thrown the first time through at all.

      Is there any reason not to allow this functionality?