Saxon

I was going to suggest you could customise the class loading using Configuration.setDynamicLoader; or you could preload the class and register it using Configuration.getDynamicLoader().registerKnownClasses.

But I see that Saxon doesn't actually use this for loading the JDBC driver. Instead (see SQLConnect.java line 173) it simply uses Class.forName(). But this is some kind of preloading: I don't understand what process the JDBC DriverManager then uses to find this loaded driver.

I see that the JDK7 documentation for DriverManager says "Applications no longer need to explictly load JDBC drivers using Class.forName(). Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification.".

Are you getting a failure from Class.forName()? Could you try commenting it out?

It seems that the recommended way of doing this these days is by using a named DataSource: see https://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html - we haven't updated this code in years.

Perhaps you could implement an extension function that you can use in place of Saxon's sql:connect to get a JDBC connection from a named datasource, i.e. implement

Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("jdbc/billingDB");
Connection con = ds.getConnection(user, password);
return con;

If that works, then we can integrate it into the product.

It all started from this forum thread: https://www.oxygenxml.com/forum/post58334.html

we have Oxygen users who for some time now have added the "mysql-connector-java-5.1.42-bin.jar"" in the Oxygen "lib" folder so that it's loaded in the main class loader. We don't really want this, we don't want them to change Oxygen's installation folder in any way, each Oxygen transformation scenario has an Extensions list in which you can add JAR libraries, usually for extension function calls. The jar libraries added there are loaded in a separate classloader which is set as context class loader on the current thread. I have not had time to build an XSLT which actually works with a mysql connection on my side. I did not yet manage to find the Java source for "net.sf.saxon.option.sql.SQLConnect ", it is not in the Saxon HE sources zip file: https://sourceforge.net/projects/saxon/files/Saxon-HE/9.9/

Somehow if you are calling Class.forName() on your side and it fails, can you also try as a fallback "Thread.currentThread().getContextClassLoader().loadClass(name)"?

I'll give it a go but it may take a few days. Getting the environment right for running the SQL tests is always a bit tricky.

No hurry, it's just something which would be nice to have, thanks for considering this.

I've got my SQL test environment with derby back up and running...

I've confirmed that the call on Class.forName(driverClass) is no longer needed, and I propose to drop it. This moves the responsibility for dynamic loading to the JDBC infrastructure so it becomes "not our problem". Of course, it's still necessary to have the right things on the classpath.

In consequence, the "driver" parameter to the sql:connect instruction and function is no longer needed (and is ignored if specified).

Thanks Michael.