WildFly server won't start using code after the 12.9.0 preview due to error with ConfigurableRetryLogic

[jocstar]

Driver version

This is actually a personal build using the code from the date of this post - the released 12.9.0 preview actually works, but the latest code as of 28/Feb/2025 does not.

SQL Server version

Microsoft SQL Server 2022 (RTM-CU15-GDR) (KB5046862) - 16.0.4155.4 (X64) Oct 18 2024 16:16:11 Copyright (C) 2022 Microsoft Corporation Developer Edition (64-bit) on Windows 10 Enterprise 10.0 (Build 19045: ) (Hypervisor)

Client Operating System

Windows10

JAVA/JVM version

Adoptium-jdk-21.0.5+11

Table schema

N/A

Problem description

I deployed my own build of the driver based on the latest 12.9.0 preview version to a WildFly server to test out a patch I was working on but the server fails to start up because of an error thrown from the JDBC driver which means it cannot create db connections.

Expected behavior

I don't expect an error looking for a configuration file(?) to prevent the driver from being used

Actual behavior

The WildFly server throws an error and cannot create a database connection at startup.

Error message/stack trace

10:16:39,326 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 103) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031084: Unable to create connection
at org.jboss.ironjacamar.jdbcadapters@1.4.35.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:364)
at org.jboss.ironjacamar.jdbcadapters@1.4.35.Final//
<< .. snip - truncated for brevity >>
Caused by: java.nio.file.FileSystemNotFoundException
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:156)
at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:142)
at java.base/java.nio.file.Path.of(Path.java:209)
at java.base/java.nio.file.Paths.get(Paths.java:98)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.getCurrentClassPath(ConfigurableRetryLogic.java:293)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.readFromFile(ConfigurableRetryLogic.java:320)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.setUpStatementRules(ConfigurableRetryLogic.java:204)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.(ConfigurableRetryLogic.java:86)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.getInstance(ConfigurableRetryLogic.java:103)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:2592)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:2199)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:1320)
at org.jboss.ironjacamar.jdbcadapters@1.4.35.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:335)

Any other details that can be helpful

The key part here is the FileSystemNotFoundException coming from ConfigurableRetryLogic.getCurrentClassPath.
It is failing on the line :
if (Files.isDirectory(Paths
.get(ConfigurableRetryLogic.class.getProtectionDomain().getCodeSource().getLocation().toURI()))) {

The URL has the form jar:file:c:...\mssql-jdbc-12.9.0.jre21-preview.jar and seems to be failing because toURL() is trying to use a ZipFileSystem but doesn't find one registered for the jar file.
When I run the JUnit tests in a dev environment, the URL has the form file:c:...\mssql-jdbc-12.9.0.jre21-preview.jar so is only looking at the file system, not within a jar and so there I don't see the problem.

JDBC trace logs

N/A as its getting a connection that is failing

[jocstar]

I rolled back Commit 83072af in my development version of the driver and Wildfly started without error.

[machavan]

Hi @jocstar

This issue has been likely addressed as part of PR # #2579

Can you please confirm and let us know?

[jocstar]

Hi @machavan
That actually seems to be the commit that introduced it. The error is coming from the newly added line

            if (Files.isDirectory(Paths
                    .get(ConfigurableRetryLogic.class.getProtectionDomain().getCodeSource().getLocation().toURI()))) {

and occurs at the toURI() part of that when the URI has a "jar:file:....." prefix. I'm not sure how or why the jar part is at the front of that URI, presumably something to do with the JBoss classloader, its a bit beyond my knowhow at that point.

[Jeffery-Wasty]

Hi @jocstar,

You're correct in that the issue appears to be the scheme prefix. I've made changes to the ConfigurableRetryLogic.getCurrentClassPath() code that I believe resolves the issue. If you have the opportunity, can you test the below custom driver?

mssql-jdbc-12.9.0.jre21-preview.zip

[jocstar]

@Jeffery-Wasty
I tried the updated file you provided, but sadly no. The error has changed, stack trace attached below :

00:01:16,495 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (ServerService Thread Pool -- 102) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: IJ031084: Unable to create connection
	at org.jboss.ironjacamar.jdbcadapters@1.4.35.Final//org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:364)

<< snip >>

	... 39 more
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 3: ile:/C:/jboss/wildfly-24.0.0.Final-JAVA21/modules/system/layers/base/com/microsoft/sqlserver/jdbc/main/mssql-jdbc-12.9.0.jre21-preview.jar!
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:204)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:175)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:231)
	at java.base/java.nio.file.Path.of(Path.java:148)
	at java.base/java.nio.file.Paths.get(Paths.java:69)
	at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.getCurrentClassPath(ConfigurableRetryLogic.java:298)
	... 47 more

looks like an "off by one" error

[Jeffery-Wasty]

Okay thanks for the feedback! I see the mistake I made. The issue is the .getSchemeSpecificPart() method only removes the jar: or file: part, but not the entire 'jar:file: prefix that we see in your case. I've changed the code to adjust for this and are looking at merging this for the next release.