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 

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://" 
> 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

To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to