Issue created: https://issues.apache.org/jira/browse/LOG4J2-424
2013/10/12 Gary Gregory <garydgreg...@gmail.com>
> Yes, please open a Jira
>
> Gary
> Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone
>
>
> -------- Original message --------
> From: Tihomir Meščić **
> Date:10/12/2013 10:16 AM (GMT-05:00)
> To: Log4J Developers List **
> Subject: Re: Missing feature in the JDBC appender
>
> So, should I open a JIRA issue for this or you guys gonna handle that?
>
> Kind regards,
> Tihomir
>
>
> 2013/10/11 Gary Gregory <garydgreg...@gmail.com>
>
>> On Fri, Oct 11, 2013 at 11:50 AM, Nick Williams
>> <nicho...@nicholaswilliams.net> wrote:
>> >
>> > On Oct 11, 2013, at 10:29 AM, Gary Gregory wrote:
>> >
>> >> On Fri, Oct 11, 2013 at 11:10 AM, Nick Williams
>> >> <nicho...@nicholaswilliams.net> wrote:
>> >>> (Foreword: Apologies for my scarcity of late. I'm a month behind on
>> my book, mostly due to my wasted work on getCallerClass for Java 8, and I
>> still have $work to contend with.)
>> >>>
>> >>> Agreed that the unicode stuff is a problem with a non-compliant
>> driver. There's nothing we can do about that per se. Other, compliant
>> drivers will require unicode columns to use setNString, etc. Unicode is the
>> direction everything is headed (indeed, most things are unicode by default
>> now, such as MySQL), so we need to leave unicode as the default.
>> >>>
>> >>> The data types are an interesting problem. We can't just support any
>> Type constant. Here's why:
>> >>>
>> >>> The way you use the Types constant is to call setObject. The problem
>> with setObject is that the actual value passed to it must match the Type
>> constant passed to it. So, you can't pass a String into setObject and use
>> Types.INTEGER--that will result in an error for most drivers (though some
>> are more forgiving).
>> >>>
>> >>> The way the whole JDBCAppender works is to use the pattern layout to
>> determine column value. This gives the end user ultimate flexibility--they
>> can use one field or multiple fields from a LogEvent for each column,
>> format them different ways, etc. The pattern layout results in a String, so
>> we need to be aware of how to convert that String to the Type the user has
>> specified. That's a lot of work, and may not be possible for all Types the
>> user can specify.
>> >>>
>> >>> However, I _do_ understand how our users could often need to have
>> integer columns, so I think it's worth adding a special case for integer
>> column types. Of course, integer columns could be either INTEGER or BIGINT
>> in the most common cases, so I'm not completely sure the best way to
>> proceed with that.
>> >>>
>> >>> Thoughts?
>> >>
>> >> I was thinking of using Types values to then have a switch on the type
>> >> value in order to call setInt vs. setString vs. setXXX
>> >>
>> >> The string could be anything but using the names Types constants gives
>> >> us a known vocabulary of sorts.
>> >
>> > But like I pointed out, we can't support a majority of the Types. What
>> we CAN do, however, is remove the "unicode" attribute and replace it with a
>> "type" attribute that initially supports values VARCHAR, NVARCHAR, INTEGER,
>> and BIGINT and defaults to NVARCHAR. These names are equivalent to the
>> Types constants, but the semantic difference is we would only document
>> these four values instead of documenting "use a constant from Types." This
>> would give us the flexibility to support further types in the future
>> without confusing the user by having to list the 33 constants that they
>> CAN'T use. What about that?
>>
>> Brilliant, wise and future proof. I like it!
>>
>> Gary
>>
>> >
>> > Nick
>> >
>> >>
>> >> Gary
>> >>
>> >>>
>> >>> Nick
>> >>>
>> >>> On Oct 9, 2013, at 5:06 PM, Gary Gregory wrote:
>> >>>
>> >>>> I'd like Nick's feedback on this, so let's see what he has to say.
>> >>>>
>> >>>> WRT process, you should use JIRA to create feature requests and bug
>> >>>> reports. You can than attach SVN a unified diff file to a JIRA. It is
>> >>>> always nice when I see unit tests in the patches too :)
>> >>>>
>> >>>> IMO, about the Unicode stuff, the modern current APIs should be the
>> >>>> default, so I would not change it. Remember that you are dealing with
>> >>>> a non-compliant JDBC driver here, if the driver claims to be JDBC 4
>> >>>> but does not implement all the APIs, then you know who to blame ;)
>> >>>>
>> >>>> Gary
>> >>>>
>> >>>> On Wed, Oct 9, 2013 at 5:55 PM, Tihomir Meščić <
>> tihomir.mes...@gmail.com> wrote:
>> >>>>> Yes, something like that would be great, since this is not only an
>> issue
>> >>>>> with the Integer type, other data types
>> >>>>> are also not supported. I've made my own implementation of the JDBC
>> appender
>> >>>>> that does exactly that. I don't
>> >>>>> know what's the policy of the project, but I'll be happy to
>> contribute the
>> >>>>> code.
>> >>>>>
>> >>>>> There is one more very nasty issue with the JDBC appender - the
>> appender
>> >>>>> will call setNString() method
>> >>>>> on the PreparedStatement by default (this is the unicode version,
>> available
>> >>>>> in JDBC version 4). When using PostgreSQL
>> >>>>> database with the latest JDBC driver this will cause an error when
>> >>>>> inserting. It looked like a bug in log4j but then
>> >>>>> (after a couple of hours of digging through log4j code) it turned
>> out that
>> >>>>> the JDBC driver for Postgres only partially implements JDBC
>> >>>>> version 4 (it does not implement the setNString method) and nobody
>> knows
>> >>>>> when it'll implement the spec completely.
>> >>>>> The fix was to set <Column isUnicode="false" in the appender
>> configuration -
>> >>>>> that way, the setString() method on the PreparedStatement
>> >>>>> would be called.
>> >>>>> IMHO, a more conservative, backwards compatible solution
>> (non-Unicode)
>> >>>>> should be the default...
>> >>>>>
>> >>>>> Kind regards,
>> >>>>> Tihomir
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 2013/10/9 Gary Gregory <garydgreg...@gmail.com>
>> >>>>>>
>> >>>>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>> >>>>>> <tihomir.mes...@gmail.com> wrote:
>> >>>>>>> Ok, my database (Postgresql) has a table (log_entries) that's
>> used for
>> >>>>>>> logging purposes.
>> >>>>>>> One of the attributes is of type INTEGER.
>> >>>>>>> In the new version of the app we are migrating to log4j version 2
>> >>>>>>> (beta9)
>> >>>>>>> and we want to
>> >>>>>>> use the JDBCAppender that bundled with log4j. The INTEGER
>> attribute is
>> >>>>>>> something specific for our
>> >>>>>>> application and we are using ThreadContext (MDC) to set the value
>> of the
>> >>>>>>> parameter.
>> >>>>>>>
>> >>>>>>> Currently, log4j provides no support for integer type attributes
>> in the
>> >>>>>>> Column element of the JDBC appender
>> >>>>>>> configuration (the only things supported are string (default),
>> timestamp
>> >>>>>>> -
>> >>>>>>> isEventTimestamp flag and Clob - isCLob flag).
>> >>>>>>>
>> >>>>>>> When using the default settings in the Column element of the JDBC
>> >>>>>>> appender
>> >>>>>>> log4j will create a prepared statement
>> >>>>>>> and try to set the value using the Statement.setString() method.
>> Of
>> >>>>>>> course,
>> >>>>>>> the JDBC driver throws an excpetion:
>> >>>>>>>
>> >>>>>>> Caused by: org.postgresql.util.PSQLException: ERROR: column
>> "mn_type_d"
>> >>>>>>> is
>> >>>>>>> of type integer but expression is of type character varying
>> >>>>>>> Hint: You will need to rewrite or cast the expression.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> My appender:
>> >>>>>>>
>> >>>>>>> <JDBC name="jdbcAppender" tableName="log_entries">
>> >>>>>>> <DriverManager url="jdbc:postgresql://10.28.10.32:5432/xxx"
>> >>>>>>> username="xxx" password="xxx" />
>> >>>>>>> <Column name="log_entries_id"
>> >>>>>>> literal="nextval('hibernate_sequence')"
>> >>>>>>> />
>> >>>>>>>
>> >>>>>>> .....
>> >>>>>>> <Column name="message" isUnicode="false" pattern="%message" />
>> >>>>>>>
>> >>>>>>> <Column name="mn_type_d" isUnicode="false"
>> pattern="%X{mn_type_d}"
>> >>>>>>> />
>> >>>>>>> <-- this is of type integer in the DB but LOG4J tries to insert
>> it as a
>> >>>>>>> String -->
>> >>>>>>> </JDBC>
>> >>>>>>
>> >>>>>> So maybe we need to be able to say:
>> >>>>>>
>> >>>>>> <Column name="mn_type_d" pattern="%X{mn_type_d}" type="INTEGER" />
>> >>>>>>
>> >>>>>> Where type is a name from java.sql.Types.
>> >>>>>>
>> >>>>>> Nick? Thoughts?
>> >>>>>>
>> >>>>>> Gary
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Kind regards,
>> >>>>>>> Tihomir
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2013/10/9 Gary Gregory <garydgreg...@gmail.com>
>> >>>>>>>>
>> >>>>>>>> Hi Tihomir,
>> >>>>>>>>
>> >>>>>>>> Can you be more descriptive please with a practical example?
>> >>>>>>>>
>> >>>>>>>> Gary
>> >>>>>>>>
>> >>>>>>>> On Wed, Oct 9, 2013 at 10:43 AM, Tihomir Meščić
>> >>>>>>>> <tihomir.mes...@gmail.com> wrote:
>> >>>>>>>>> Hi everyone,
>> >>>>>>>>>
>> >>>>>>>>> there is a missing feature in the JDBCAppender for log4j
>> version 2,
>> >>>>>>>>> it
>> >>>>>>>>> does
>> >>>>>>>>> not support data types
>> >>>>>>>>> other than string, date and clob. So for example, if the table
>> you
>> >>>>>>>>> are
>> >>>>>>>>> trying to log to has an Integer
>> >>>>>>>>> column, there is way to force log4j to insert it. I ended up
>> writing
>> >>>>>>>>> my
>> >>>>>>>>> own
>> >>>>>>>>> JDBC appender. I think
>> >>>>>>>>> that this feature is very important and it should definitively
>> be
>> >>>>>>>>> included
>> >>>>>>>>> in the final version.
>> >>>>>>>>>
>> >>>>>>>>> Log4j version: 2.0.0-beta9
>> >>>>>>>>>
>> >>>>>>>>> Kind regards,
>> >>>>>>>>> Tihomir
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >>>>>>>> Java Persistence with Hibernate, Second Edition
>> >>>>>>>> JUnit in Action, Second Edition
>> >>>>>>>> Spring Batch in Action
>> >>>>>>>> Blog: http://garygregory.wordpress.com
>> >>>>>>>> Home: http://garygregory.com/
>> >>>>>>>> Tweet! http://twitter.com/GaryGregory
>> >>>>>>>>
>> >>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> >>>>>>>> For additional commands, e-mail:
>> log4j-dev-h...@logging.apache.org
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >>>>>> Java Persistence with Hibernate, Second Edition
>> >>>>>> JUnit in Action, Second Edition
>> >>>>>> Spring Batch in Action
>> >>>>>> Blog: http://garygregory.wordpress.com
>> >>>>>> Home: http://garygregory.com/
>> >>>>>> Tweet! http://twitter.com/GaryGregory
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> >>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >>>> Java Persistence with Hibernate, Second Edition
>> >>>> JUnit in Action, Second Edition
>> >>>> Spring Batch in Action
>> >>>> Blog: http://garygregory.wordpress.com
>> >>>> Home: http://garygregory.com/
>> >>>> Tweet! http://twitter.com/GaryGregory
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >> Java Persistence with Hibernate, Second Edition
>> >> JUnit in Action, Second Edition
>> >> Spring Batch in Action
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>> >>
>> >
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>
>>
>
