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ć <tihomir.mes...@gmail.com>
Date:10/12/2013 10:16 AM (GMT-05:00)
To: Log4J Developers List <log4j-dev@logging.apache.org>
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
