Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Migrate logging to java.util.logging [JDBC182] #229

Closed
firebird-automations opened this issue Sep 2, 2011 · 11 comments
Closed

Migrate logging to java.util.logging [JDBC182] #229

firebird-automations opened this issue Sep 2, 2011 · 11 comments
Assignees
@mrotteveel
Labels
component: jdbc driver fix-version: Jaybird 3.0.0 priority: trivial resolution: fixed type: improvement

Comments

@firebird-automations
Copy link

Submitted by: @mrotteveel

Jaybird currently supports the use of Log4J 1.x, this no longer works in Java 9 and is also end-of-life (see https://blogs.apache.org/logging/entry/moving_on_to_log4j_2).

We are going to replace the logging with java.util.logging.

Switching to a different logging framework like SLF4J brings too many headaches when it comes to dependencies, etc. So java.util.logging is the only viable choice for a JDBC driver. This may also allow for future support of some of the log-related methods added in JDBC 4.1 (eg CommonDataSource.getParentLogger())

OLD:

Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

Commits: 722edb9 344af16
@firebird-automations
Copy link
Author

Commented by: Roman Rokytskyy (rrokytskyy)

If I remember correctly, we have abstracted that stuff via our own logger class, which starts to work only when Log4J is in the classpath.

I suggest to add support for SLF4J the same way, but keep the existing class there... maybe some kind of fallback, e.g. try SLF4J, if not there, then Log4J, if not there - java.util.logging. I had some incompatibility issues with SLF4J in my other project (though I did not check the exact reason), so I would like to avoid having hard dependency on SLF4J in the driver.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

I am not in favour of having a facade to the logging facade, as it duplicates the whole intention of SLF4J (and usually does so while making it more brittle and less feature rich) :). It usually also makes the log information less clear, see also http://www.slf4j.org/faq.html#optional_dependency
In the current implementation of SLF4J it falls back to a no-operation logger when there is no bridge to an actual logger available (this should remove any errors for missing loggers etc).

It would be good to know what kind of problem you had. The only potential problem cases I know of is having two different versions of the SLF4J API jar and/or a mismatch between versions of the logging-bridge jar and the SLF4J API version that is loaded. That is a problem usually resolved by the end developer making sure he includes matching API and bridge jar versions (the 'user' side of the SLF4J API is very stable, so including a lower version than shipped with Jaybird should also work, see http://www.slf4j.org/faq.html#compatibility ).

@firebird-automations
Copy link
Author

Commented by: Roman Rokytskyy (rrokytskyy)

Issue was that when it was in the classpath together with commons-logging, the project did not start with some exception re. the different method signatures either in commons-logging or in slf4j classes. As soon as I removed the slf4j classes, it worked fine.

The issue was that I did not use any logger in my code at all. The different loggers came with different logging libraries used by different 3rd party components and I had to find out what combination worked finally.

I also do not see big advantage of having logging in the driver at all, since no user is interested in the internal flow inside the driver at all. So I would rather think about is injecting the logging code on the fly using some aspect-oriented library or keep it as it is (maybe add a java.util.logging proxy to make things complete)...

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Sounds like that project contained the SLF4J commons-logging replacement jar (jcl_over_slf4j.jar which is intended as a drop-in replacement of commons-logging to access the logging facility bridged by slf4j) and not just the slf4j API. In that case you do get conflicts with same/similar classnames if both jars are on the classpath. See http://www.slf4j.org/legacy.html

I think some basic logging can have merit, and aspect-oriented logging does take (some) performance hits, maybe we should shelf this for the time being and maybe rethink our logging strategy :)

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

priority: Minor [ 4 ] => Trivial [ 5 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

assignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ]

description: Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

=>

Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

summary: Migrate logging to SLF4J => Migrate logging to SLF4J or java.util.logging

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

description: Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

=>

Jaybird currently supports the use of Log4J 1.x, this no longer works in Java 9 and is also end-of-life (see https://blogs.apache.org/logging/entry/moving_on_to_log4j_2).

We are going to replace the logging with java.util.logging.

Switching to a different logging framework like SLF4J brings too many headaches when it comes to dependencies, etc. So java.util.logging is the only viable choice for a JDBC drtiver.

OLD:

Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

summary: Migrate logging to SLF4J or java.util.logging => Migrate logging to java.util.logging

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 3.0 [ 10440 ]

description: Jaybird currently supports the use of Log4J 1.x, this no longer works in Java 9 and is also end-of-life (see https://blogs.apache.org/logging/entry/moving_on_to_log4j_2).

We are going to replace the logging with java.util.logging.

Switching to a different logging framework like SLF4J brings too many headaches when it comes to dependencies, etc. So java.util.logging is the only viable choice for a JDBC drtiver.

OLD:

Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

=>

Jaybird currently supports the use of Log4J 1.x, this no longer works in Java 9 and is also end-of-life (see https://blogs.apache.org/logging/entry/moving_on_to_log4j_2).

We are going to replace the logging with java.util.logging.

Switching to a different logging framework like SLF4J brings too many headaches when it comes to dependencies, etc. So java.util.logging is the only viable choice for a JDBC driver. This may also allow for future support of some of the log-related methods added in JDBC 4.1 (eg CommonDataSource.getParentLogger())

OLD:

Currently Jaybird depends on Log4J which is a specific logging implementation. Using a specific logging implementation might conflict with other loggers (or at least complicate matters for developers using a different logger).

I suggest we migrate to SLF4J (Simple Logging Facade for Java), which is a logging facade that allows developers to plugin a bridge to their own logging facility (eg to Log4J, java.util.logging, Logback, apache commons-logging).

Another option would be to migrate to java.util.logging. This would entirely remove the need for external logging dependencies.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Added support for `java.util.logging`, and made it the default logging
implementation.

We have applied the following mapping for the log levels:

* `Logger.trace`: `Level.FINER`
* `Logger.debug`: `Level.FINE`
* `Logger.info`: `Level.INFO`
* `Logger.warn`: `Level.WARNING`
* `Logger.error`: `Level.SEVERE`
* `Logger.fatal`: `Level.SEVERE`

We have also added some options to control logging behavior:

* System property `org.firebirdsql.jdbc.disableLogging` with value `true`
will disable logging entirely.
* System property `org.firebirdsql.jdbc.forceConsoleLogger` with value `true`
will force logging to the `System.out` for info and lower and `System.err`
for warn and above (`debug` and `trace` are disabled in the implementation).
* System property `org.firebirdsql.jdbc.loggerImplementation` to specify an
alternative implementation of the interface `org.firebirdsql.logging.Logger`.

This implementation must be public and must have a public constructor with
a single \`String\` argument for the logger name\. See also 
\[Support for log4j 1\.x removed\] for an example\.

The \`org\.firebirdsql\.logging\.Logger\` interface is volatile and might change 
in future minor releases \(but not point/bugfix releases\)\.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mrotteveel mrotteveel

Labels
component: jdbc driver fix-version: Jaybird 3.0.0 priority: trivial resolution: fixed type: improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mrotteveel @firebird-automations