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.
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
