logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-424) JDBCAppender: Add support for data types other then String
Date Tue, 18 Oct 2016 16:57:00 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585969#comment-15585969
] 

Remko Popma edited comment on LOG4J2-424 at 10/18/16 4:56 PM:
--------------------------------------------------------------

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

There is a class called ThreadContextAccess which gives access to the internals (this is how
the ContextInjector in Log4j core accesses the underlying ThreadContextMap implementation).
This will work in 2.7 but it is documented as "not for application use". This class 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. 


was (Author: remkop@yahoo.com):
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message