Investigate classloader use when loading FirebirdEmbeddedProvider SPI

[mrotteveel]

See also https://groups.google.com/g/firebird-Java/c/SjPV2HAG1Q4

As discussed there, we may also want to try the classloader of the FirebirdEmbeddedProvider SPI (just like we do when loading other SPIs).

[prrvchr]

Thanks Mark.
I will try to compile with the specified changes to verify that they behave as expected.
I've never compiled Jaybird before, so I hope this is easy.

[prrvchr]

Well, actually, I haven't managed to compile Jaybird.

But I think the modification is quite simple; you just need to specify the caller's class loader when delivering an SPI service.
ie: ServiceLoader.load(FirebirdEmbeddedProvider.class, FirebirdEmbeddedLookup.class.getClassLoader());

This allows:

• Obtaining an SPI service in the same way you obtain a Class instance with new or Class.forName().

• No longer requiring the SPI service to be placed in the Java classpath, which allows it to be loaded dynamically (via a URLClassLoader).

• Ensuring that the use of SPI services follows and benefits from the ClassLoader inheritance logic.

[mrotteveel]

Well, actually, I haven't managed to compile Jaybird.

Could you maybe create a ticket, or post on firebird-java what problems you ran into?

The build should be straightforward, run ./gradlew (though tests will fail, if you don't have Firebird running on localhost port 3050 with sysdba/masterkey, or the default directory the build uses for the database is not accessible by the server), you can override this (e.g. -Ptest.password=<your password>; on PowerShell, you may have to use -P'test.password'=<your password>) See gradle.properties under "Default test configuration".

Or if you want to only build: ./gradlew assemble

[mrotteveel]

In any case, I haven't had time to check yet. I'll try next week.

[prrvchr]

Hi Mark,

Thank you for looking into this issue, which apparently only affects me.

With your information, I'll try compiling again without the tests to make sure what I'm saying is correct.

I'll get back to you to confirm.

[mrotteveel]

Thank you for looking into this issue, which apparently only affects me.

To be honest, I don't think people have very actively used the FirebirdEmbeddedProvider, or only in simple classpath/classloader setups.

[mrotteveel]

I don't think I have sufficient information to understand the problem you're having, and what the solution would be. As far as I can tell, your suggested solution to use FirebirdEmbeddedLookup.class.getClassLoader() with ServiceLoader.load would not address the problem if the SPI implementation is in a different classloader than Jaybird itself, while the current solution does, as long as the context classloader of the current thread can reach both.

Could you write a simple application that demonstrates the classloading issue?

[mrotteveel]

For example, this program can load the embedded library just fine, even though it is not in the initial classpath (jaybird and jaybird-native are):

public class Main {

    private static final Path FIREBIRD_EMBEDDED_JAR = Path.of(
            "C:/Users/mark/.m2/repository/org/firebirdsql/embedded/jaybird-firebird-embedded-win32-x86-64",
            "5.0.3.0-alpha-1",
            "jaybird-firebird-embedded-win32-x86-64-5.0.3.0-alpha-1.jar");

    public static void main(String[] args) throws SQLException, MalformedURLException {
        var cl = new URLClassLoader("firebird-embedded-classloader",
                new URL[] { FIREBIRD_EMBEDDED_JAR.toUri().toURL() },
                ClassLoader.getSystemClassLoader());

        Thread.currentThread().setContextClassLoader(cl);

        var props = new Properties();
        props.setProperty("user", "sysdba");
        props.setProperty("password", "");
        props.setProperty("createDatabaseIfNotExist", "true");
        props.setProperty("set_db_charset@create", "utf8");
        try (var connection = DriverManager.getConnection(
                "jdbc:firebird:embedded:C:/DevTemp/spi-use-custom-cl.fdb", props);
             var stmt = connection.createStatement();
             var rs = stmt.executeQuery("select {fn DATABASE()} from RDB$DATABASE")) {
            if (rs.next()) {
                System.out.println(rs.getString(1));
            }
        }
    }
}

[prrvchr]

Hi Mark,

Thank you for wasting your time on this problem.

Indeed, if we use the instruction:
Thread.currentThread().setContextClassLoader(cl);
then everything works perfectly.

But if I take for example the deployment of an SPI service for java.lang.System.Logger then changing Thread.currentThread().setContextClassLoader(cl) (and then resetting it after loading as it should) when loading the JDBC driver may not be sufficient because calls to the logging service may be made after the driver itself has been loaded.

That's certainly what I've noticed.

For now, in such cases, my only solution is to add my SPI service (i.e., java.lang.System.LoggerFinder) to the Java classpath.

So perhaps not trying to restore the Thread.currentThread().setContextClassLoader(cl) and leaving it as is, is the solution?

[mrotteveel]

I think you should be able to reset the context class loader after the first connection has been made (creating the first connection is what causes the Firebird Embedded provider to be loaded, not loading the JDBC driver itself, as loading the driver itself must be relatively "cheap"). Alternatively, I think using System.getLogger() should trigger loading of the System.LoggerFinder SPI (you may need to explicitly log something?)

[mrotteveel]

That said, I do think that Java pretty much requires the logger SPI to be on the initial classpath; you run the risk of a class loader leak if you don't.

[mrotteveel]

Also, I was thinking, maybe the class loader you currently use needs to use the previous context class loader as its parent, and not the system class loader.