[
https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585969#comment-15585969
]
Remko Popma commented on LOG4J2-424:
------------------------------------
Potentially yes, but...
The good news is that while the ThreadContext facade only lets you put String
values, since 2.7 the underlying data structure accepts Object values. The
question then becomes how do applications gain access to the underlying data
structure.
Unfortunately we haven't really thought this part through yet.
The ThreadContextMap implementation can be replaced via a system property. This
allows applications to switch to a garbagefree implementation or a custom
implementation etc, but putting values still goes through the ThreadContext
facade, which doesn't give the application access to any new feature provided
by this ThreadContextMap implementation...
ThreadContextAccess allows access to the internals (this is how the
ContextInjector in Log4j core accesses the underlying ThreadContextMap
implementation). This will work in 2.7 but is documented as "not for
application use". It may go away in future versions if we find a better way, so
be aware that if you rely on ThreadContextAccess, your code may break with any
Log4j upgrade.
We need to think about how we can extend the ThreadContext facade or allow
custom facades or provide some other way for applications to access any
additional API that their ThreadContextMap implementation provides.
> JDBCAppender: Add support for data types other then String
> ----------------------------------------------------------
>
> Key: LOG4J2-424
> URL: https://issues.apache.org/jira/browse/LOG4J2-424
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
> Affects Versions: 2.0-beta9
> Environment: All
> Reporter: Tihomir Meščić
> Assignee: Nick Williams
>
> I am using the JDBCAppender to log to a Postgresql database. I have a table
> (log_entries) that's used for logging purposes.
> One of the attributes is of type INTEGER. The 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 types 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 exception:
> 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 configuration:
> <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>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
