adrianshum / jdbcdslog Goto Github PK

View Code? Open in Web Editor NEW

This project forked from jdbcdslog/jdbcdslog

36.0 6.0 7.0 721 KB

Fork of jdbcdslog-exp, which includes more features

Java 100.00%

jdbcdslog's Introduction

What is JdbcDsLog-Exp2

jdbcdslogexp2 is an fork of [jdbcdslog-exp] that, on top of the features provided by jdbcdslog-exp, provides:

Support vendor-extended JDBC interfaces, so that when calling unwrap(), a vendor-interface-proxied object will still be returned, which will allow you to use vendor specific feature, and yet still being logged with JDBC DS Log messages.
Allow you to choose from inline-parameter-style (as in jdbcdslog-exp) or separate-parameter-style (similar to original jdbcdslog) in query log.
More flexible and useful stack trace printing, which allow you to
- print full stack trace.
- print first level outside of JDBC DS log call stack (Default behavior).
- print first level matching a pattern you provide. This is especially useful if your DB access is going through some framework like Hibernate. Then you can show the first frame in call stack of your own package.
- (All above options excludes stack frames of JDBC DS Log)
Better ResultSet logging
- Individual row is logged in debug level, with row number.
- Call to ResultSet#next() after the last row will trigger a summary log message which contains total fetch time and total number of records.
Can log before and after statement invocations. Statement logging can be turned off in "after" logging.
Better handling in batch-operations.
- executeBatch() will now be logged. You can, optionally, log all statements in batch.
- addBatch() can be logged with less detail or excluded from logging completely.
Dropped pre-JDK5 support and source code is now cleaner with proper use of JDK5+ features like Generics, for-each loop etc.
Upgrade to later SLF4J version
Cleanup logging codes for readability and reduce unnecessary string constructions.
Provides Connection ID in MDC so user can (optionally) distinguish logs originated from different connectiosn, which is especially useful for application connecting to multiple DBs. (version 2.1)
Fix misc bugs and problems in original codebase. (Of course, the original function does not change!)

if you want get more information please see the original version of jdbcdslog at http://code.google.com/p/jdbcdslog/

Maven Dependency

<dependency>
    <groupId>org.jdbcdslog</groupId>
    <artifactId>jdbcdslogexp2</artifactId>
    <version>2.1</version>
</dependency>

How To Use

Please see user guide: JDBC DS Log Exp2 User Guide for JDBC DS Log Exp2 specific features.

For original user guides, please refer to Origin JdbcDsLog UserGuide and JdbcDsLog-exp UserGuide.

Support

if you have any questions,welcome to contact me via Email(adrianshum at gmail dot com) or create issues with https://github.com/adrianshum/jdbcdslog/issues, I will reply you as soon as possible.

jdbcdslog's People

Contributors

Stargazers

Watchers

Forkers

markwoon marcvg arielnetworks gaf-ag jardevbox serpro69 m-a-g-i-c

jdbcdslog's Issues

Vendor interface support

For Connection, Statement/PreparedStatement/CallableStatement and ReseultSet, instead of simply providing the JDBC-interface, the JdbcDsLog Proxy will also implement all compatible interfaces of the target. Compatible means interface that inherits the JDBC interface. e.g. If the Connection from the target datasource implements OracleConnection, Connection, and Foo. Given that OracleConnection is an interface that extends Connection, then the returned JdbcDsLog proxy will implement both OracleConnection and Connection interface. By doing so, it allow you to cast directly to the vendor interface
Provides support for isWrapperFor() and unwrap() methods in Connection, Statement/PreparedStatement/CallableStatement and ReseultSet: if the unwrapped interface is a JDBC compatible interface (as described above), a proxy implementing that vendor interface will be implemented.

Although the JDBCDsLog proxy is going to implement the vendor interfaces, logging will only be done in methods defined in JDBC standard interface.

Proper use of generics in LoggingHandlerSupport

Now it is storing Object as target, which can be improved by providing it in generic way to make cleaner code

Unnecessary ERROR log statement during init about unimplmented getNetworkTimeout() method

Every time I start my application, I get this error log statement about "org.postgresql.jdbc42.Jdbc42Connection.getNetworkTimeout() is not yet implemented."
Can this error level be reduced to INFO or at least WARN so our log monitor isn't getting false positives about something that's not really an error?

Thanks!

2016-02-05 11:41:54,642 ERROR [amazon-to-ods dev Hikari connection adder (pool OUT-POOL)] o.j.ConnectionLogger (LogUtils.java:30) jdbcdslog.connectionId=1 java.sql.Connection.getNetworkTimeout:
java.sql.SQLFeatureNotSupportedException: Method org.postgresql.jdbc42.Jdbc42Connection.getNetworkTimeout() is not yet implemented.
at org.postgresql.Driver.notImplemented(Driver.java:671) ~[postgresql-9.4-1206-jdbc42.jar:9.4]
at org.postgresql.jdbc4.AbstractJdbc4Connection.getNetworkTimeout(AbstractJdbc4Connection.java:347) ~[postgresql-9.4-1206-jdbc42.jar:9.4]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_66]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_66]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_66]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
at org.jdbcdslog.ConnectionLoggingHandler.invoke(ConnectionLoggingHandler.java:48) ~[jdbcdslogexp2-2.1.jar:na]
at com.sun.proxy.$Proxy48.getNetworkTimeout(Unknown Source) [na:na]
at com.zaxxer.hikari.pool.PoolBase.getAndSetNetworkTimeout(PoolBase.java:422) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.PoolBase.setupConnection(PoolBase.java:334) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:315) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:171) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:436) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.HikariPool.access$500(HikariPool.java:65) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:567) [HikariCP-2.4.3.jar:na]
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:560) [HikariCP-2.4.3.jar:na]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]

Allow to choose multi-line or single-line logging

Although multi-line logging is more readable, single-line logging may make analysis a bit easier. May allow choosing different style by config

Exception when it is calling from main method

Default Stack Frame lookup logic is flawed, and if it is the topmost frame in stack calling JDBC, Array Index Out Of Bound exception will be thrown.

java.lang.IllegalArgumentException: repeated interface: java.sql.Statement

2015-7-30 18:55:34 org.jdbcdslog.ConnectionLogger java.sql.Connection.createStatement:

java.lang.IllegalArgumentException: repeated interface: java.sql.Statement
    at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:597) ~[na:1.8.0_51]
    at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557) ~[na:1.8.0_51]
    at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230) ~[na:1.8.0_51]
    at java.lang.reflect.WeakCache.get(WeakCache.java:127) ~[na:1.8.0_51]
    at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419) ~[na:1.8.0_51]
    at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719) ~[na:1.8.0_51]
    at org.jdbcdslog.ProxyUtils.proxyForCompatibleInterfaces(ProxyUtils.java:46) ~[jdbcdslogexp2-2.1.jar:na]
    at org.jdbcdslog.ProxyUtils.wrapByStatementProxy(ProxyUtils.java:72) ~[jdbcdslogexp2-2.1.jar:na]
    at org.jdbcdslog.ConnectionLoggingHandler.invoke(ConnectionLoggingHandler.java:57) ~[jdbcdslogexp2-2.1.jar:na]
    at com.sun.proxy.$Proxy80.createStatement(Unknown Source) [na:na]

Here is the the configuration in test package:

@AutoConfigureBefore(LiquibaseAutoConfiguration.class)
@AutoConfigureAfter(DataSourceAutoConfiguration.class)
@Configuration
public class DataSourceLogging {

    // bean name must different from orign data source, default bean name is the method name.
    @Bean
    @Primary
    public DataSource dataSourceProxy(DataSource dataSource) throws JdbcDsLogRuntimeException {
        ConnectionPoolDataSourceProxy proxy = new ConnectionPoolDataSourceProxy();
        proxy.setTargetDSDirect(dataSource);
        return proxy;
    }
}

Allow to log before and after statement execution

Provide feature of logging before and after statement execution.

"Before" logging always includes details, and is turned on when jdbcdslog.logBeforeStatement is set to true

"After" logging can be configured to display basic info only, if jdbcdslog.logBeforeStatement is true and jdbcdslog.logDetailAfterStatement is false.

Connection identifier in log

Provide (optional) connection identifier in log message.

Will be useful if the application is connecting to multiple DB at the same time (for which it is not enough to use thread ID to link up log messages).

Suggestion: use MDC to store the connection identifier, so that people can easily configure the log message by themselves to include/exclude connection identifier

Misleading exception handling for error in executeBatch

Current exception handling logic append the latest statement to the log message but that is misleading for executeBatch. Review the way exception handling should be done

Proper batch processing logging

Currently only addBatch is logged, for which there is no DB access.

The actual execution which is executeBatch() is not logged.

The way of logging should be reworked to give a more meaningful logging in case of execute batch.

Logging should be added when executeBatch is invoked.
allow to choose if addBatch will generate logging
allow to choose if executeBatch is generating logging for individual batch. Depending on the inline style setting, we may display the log as: 1 sql, and showing individual parameters, or showing every batch as separate query.

Configure elapsed time in logging statement

Possibility to configure the following issues:
Allow to show elapsed time in milliseconds in the logging statement.
Allow to show elapsed time in the same line as the sql logging statement.

Currently the elapsed time information in the logging statement is logged in a new line in seconds and there is no posibility to configure it.

Provide Spring Helper for wrapping datasource by AOP

This should make configuration (by Spring profile) much easier as it can be done with only 1 profile with something like (not real code)

<profile name="JDBC_LOG">
    <aspect class="jdbcDsLogAspect" pointcut = "bean('datasource')" />
</profile>

Have some basic study to see if it is possible

START and END should shown only when "logBeforeStatement" is turned on.

If no logBeforeStatement option is set, there is no point showing END in statement log messages.

IllegalArgumentException: repeated interface: java.sql.Connection with HikariDataSource

java.lang.IllegalArgumentException: repeated interface: java.sql.Connection
	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:597)
	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
	at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
	at java.lang.reflect.WeakCache.get(WeakCache.java:127)
	at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
	at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
	at org.jdbcdslog.ProxyUtils.proxyForCompatibleInterfaces(ProxyUtils.java:46)
	at org.jdbcdslog.ProxyUtils.wrapByConnectionProxy(ProxyUtils.java:84)
	at org.jdbcdslog.DataSourceProxyBase.getConnection(DataSourceProxyBase.java:48)
...

This happens because HikariDataSource provides HikariProxyConnection (implements Connection) object that inherits ProxyConnection (implements Connection).

Proposed fix for method org.jdbcdslog.ProxyUtils.findCompatibleInterfaces(Class, Class) is

    /**
     * Find all interfaces of clazz that is-a requiredInterface.
     *
     * @param clazz
     * @param requiredInterface
     * @return
     */
    public static Class<?>[] findCompatibleInterfaces(Class<?> clazz, Class<?> requiredInterface) {
        IdentityHashMap<Class<?>, Object> interfaces = new IdentityHashMap<Class<?>, Object>();
        //ArrayList<Class<?>> interfaces = new ArrayList<Class<?>>();
        for ( ; ! clazz.equals(Object.class) ; clazz = clazz.getSuperclass()) {
            for (Class<?> iface : clazz.getInterfaces()) {
                if (requiredInterface.isAssignableFrom(iface)) {
                    //interfaces.add(iface);
                    interfaces.put(iface, null);
                }
            }
        }
        //return interfaces.toArray(EMPTY_CLASS_ARRAY);
        return interfaces.keySet().toArray(EMPTY_CLASS_ARRAY);
    }

Allow mentioning unit in slowQueryThreshold setting

currently it is an integer representing number of ms.

Add ability to it so that you can define slow query threshold as:

jdbcdslog.slowQueryThreshold=500       // default: ms
jdbcdslog.slowQueryThreshold=500ms     // 500 milli seconds
jdbcdslog.slowQueryThreshold=5s        // 5 seconds
jdbcdslog.slowQueryThreshold=5000ns    // 5000 nano seconds