12.4.1 fails to deploy in OSGi environment without com.ibm.lang.management

[MrEasy]

Driver version

12.4.1

SQL Server version

Microsoft SQL Server 2019 (RTM-GDR) (KB5014356) - 15.0.2095.3 (X64) Apr 29 2022 18:00:13 Copyright (C) 2019 Microsoft Corporation Developer Edition (64-bit) on Windows 10 Pro 10.0 (Build 22000: ) (Hypervisor)
(but unrelated to issue)

Client Operating System

Win 11 (but unrelated)

JAVA/JVM version

17.0.4 (but unrelated)

Problem description

This change here: https://github.com/microsoft/mssql-jdbc/pull/2198/commits

added an explicit dependency to com.ibm.lang.management in META-INF/MANIFEST.MF.

As a result, the driver will not deploy anymore in an OSGi environment without that dependency:

The class is loaded via reflection, but the maven-bundle-plugin is too 'intelligent', recognizes it and constructs a mandatory import for it.
You need to explicitly declare the dependency as optional in pom.xml. See pull request #2208.
See #1892 for a very similar issue.

Expected behavior

Dependency declared optional and deploying without successfully.

[lilgreenbird]

hi @MrEasy

thanks this we will look into a fix

[MrEasy]

#2209 also addresses this

[krismarc]

@Jeffery-Wasty and this one when will be released? Not sure why the class being checked was changed in the last moment.

[Jeffery-Wasty]

Hi @krismarc,

EDIT: 12.4.2 is delayed for the time being. Will update when we have a date again.

This change will be included in an additional hotfix for 12.4, 12.4.2. We don't currently have a date for this release, but are working to get this out as soon as we can.

The change was made as, while the class check is more robust, it requires additional changes in other files that we did not want to make. The vm.name and vendor.name check does the same job and is contained to only the one file.

[Jeffery-Wasty]

@MrEasy, do you have a workaround for this issue at the moment? We're unable to test in an OSGi environment, so we can't confirm whether a workaround exists, but we believe some fiddling with the manifest files should give a temporary resolution. The hotfix is currently scheduled for Sept 21, but this may change depending on the availability of a current workaround.

[MrEasy]

Hi, workaround is to edit the manifest and add the ;resolution:=optional, yes.
Or doing that in a fork and build it accordingly, but our actual way of handling it though is to not yet update to 12.4.1.