You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Tihomir Meščić <ti...@gmail.com> on 2013/10/09 16:43:50 UTC
Missing feature in the JDBC appender
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
Re: Missing feature in the JDBC appender
Posted by Tihomir Meščić <ti...@gmail.com>.
So, should I open a JIRA issue for this or you guys gonna handle that?
Kind regards,
Tihomir
2013/10/11 Gary Gregory <ga...@gmail.com>
> On Fri, Oct 11, 2013 at 11:50 AM, Nick Williams
> <ni...@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
> >> <ni...@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.mescic@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 <ga...@gmail.com>
> >>>>>>
> >>>>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
> >>>>>> <ti...@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 <ga...@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ć
> >>>>>>>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >>>>>>>> For additional commands, e-mail:
> log4j-dev-help@logging.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Missing feature in the JDBC appender
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Oct 11, 2013 at 11:50 AM, Nick Williams
<ni...@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
>> <ni...@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ć <ti...@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 <ga...@gmail.com>
>>>>>>
>>>>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>>>>>> <ti...@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 <ga...@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ć
>>>>>>>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing feature in the JDBC appender
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Oct 11, 2013, at 10:29 AM, Gary Gregory wrote:
> On Fri, Oct 11, 2013 at 11:10 AM, Nick Williams
> <ni...@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?
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ć <ti...@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 <ga...@gmail.com>
>>>>>
>>>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>>>>> <ti...@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 <ga...@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ć
>>>>>>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Re: Missing feature in the JDBC appender
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Oct 11, 2013 at 11:10 AM, Nick Williams
<ni...@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ć <ti...@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 <ga...@gmail.com>
>>>>
>>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>>>> <ti...@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 <ga...@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ć
>>>>>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing feature in the JDBC appender
Posted by Nick Williams <ni...@nicholaswilliams.net>.
(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?
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ć <ti...@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 <ga...@gmail.com>
>>>
>>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>>> <ti...@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 <ga...@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ć
>>>>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Re: Missing feature in the JDBC appender
Posted by Gary Gregory <ga...@gmail.com>.
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ć <ti...@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 <ga...@gmail.com>
>>
>> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
>> <ti...@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 <ga...@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ć
>> >> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>
>> >
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing feature in the JDBC appender
Posted by Tihomir Meščić <ti...@gmail.com>.
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 <ga...@gmail.com>
> On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
> <ti...@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 <ga...@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ć
> >> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Missing feature in the JDBC appender
Posted by Gary Gregory <ga...@gmail.com>.
On Wed, Oct 9, 2013 at 11:24 AM, Tihomir Meščić
<ti...@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 <ga...@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ć
>> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Missing feature in the JDBC appender
Posted by Tihomir Meščić <ti...@gmail.com>.
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>
Kind regards,
Tihomir
2013/10/9 Gary Gregory <ga...@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ć
> <ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Missing feature in the JDBC appender
Posted by Gary Gregory <ga...@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ć
<ti...@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: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org