[BUG] OSS JDBC initializes FileHandler when log level is LogLevel.OFF causing connection failure

[AndreiRudkouski]

Describe the bug
When log level is set to LogLevel.OFF (default value), the Databricks OSS JDBC driver still initializes the JUL FileHandler and attempts to create log lock files such as:
/databricks_jdbc.log.0.lck
In containerized or restricted environments (Docker, Kafka Connect, read-only filesystem), this results in:

com.databricks.jdbc.exception.DatabricksSQLException: Error initializing the Java Util Logger (JUL) with error: /databricks_jdbc.log.0.lck
    at com.databricks.jdbc.common.util.DriverUtil.setUpLogging(DriverUtil.java:79)
    at com.databricks.client.jdbc.Driver.connect(Driver.java:60)
    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:683)
    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:191)
    at com.tealium.inboundconnectors.jdbc.api.management.services.remoteconnection.JDBCRemoteClient.getConnection(JDBCRemoteClient.java:199)
    at com.tealium.inboundconnectors.jdbc.api.management.services.remoteconnection.JDBCRemoteClient.executeWithConnection(JDBCRemoteClient.java:203)
    ... 35 more
Caused by: java.nio.file.AccessDeniedException: /databricks_jdbc.log.0.lck
    at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
    at java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:224)
    at java.base/java.nio.channels.FileChannel.open(FileChannel.java:309)
    at java.base/java.nio.channels.FileChannel.open(FileChannel.java:369)
    at java.logging/java.util.logging.FileHandler.openFiles(FileHandler.java:512)
    at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:451)
    at java.logging/java.util.logging.FileHandler.<init>(FileHandler.java:409)
    at com.databricks.jdbc.log.JulLogger.initLogger(JulLogger.java:160)
    at com.databricks.jdbc.common.util.LoggingUtil.setupLogger(LoggingUtil.java:22)
    at com.databricks.jdbc.common.util.DriverUtil.setUpLogging(DriverUtil.java:69)
    ... 40 more

As a consequence, the very first connection attempt fails before any network communication with Databricks occurs.

An additional inconsistency has been observed: on subsequent connection attempts, the handler is no longer initialized and the connection succeeds.

Currently, the only way to avoid this exception is to explicitly redirect logging to STDOUT:
logpath=STDOUT

To Reproduce

• Run Databricks OSS JDBC driver in a container with restricted or read-only root filesystem.

• Set log level to OFF (default value without any additional properties).

• Do not specify an explicit log path.

• Attempt to establish a JDBC connection.

  Result:

• First attempt fails with AccessDeniedException for /databricks_jdbc.log.0.lck.

• Subsequent attempts succeed.

Expected behavior

When log level is set to OFF:

• Logger handler should not be initialized.
• No filesystem interaction should occur.
• No lock files should be created.
• Connection should succeed consistently on all attempts.

Client Environment (please complete the following information):

• OS: MacOS
• Java version: Java 17
• Java vendor: graalvm
• Driver Version 1.0.11-oss

Additional context
The driver currently initializes the JUL FileHandler regardless of the log level, and only applies the OFF level after the handler is created. This leads to unnecessary filesystem access and failures in restricted environments.

Suggested improvement:

• Skip logger initialization entirely when log level is OFF
  OR
• Initialize a No-Op handler that does not publish logs.