Hello Bryan, At present time, DBAppender merges properties "defined in the context***" as well as those properties defined in the current MDC into a single map and then persists that map on the database. There is no configuration setting to change that behavior. ***Any property defined during configuration is "defined in the context" and lives as long as the applications or is changed. I think that it would be possible to solve the issue you are facing by separating properties which should live during logback configuration (and then cease to exists) and properties which should live as long as the application. In any case, the problem you describe needs to be fixed. Could you please enter a bug report? Thank you, -- QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is looking to hire talented software developers. For further details, see http://logback.qos.ch/job.html On 27/05/2011 11:40 AM, Bryan Ward wrote:
Hello,
I'm using the DBAppender and the MDC to log certain elements of the requests into our application.
I've noticed that besides just the elements that I've put in the MDC, all of the system properties are also being logged to the logging_event_property table. This has caused many concerns because there are certain system properties that should not be logged.
Here is my DB Appender configuration
<appender name="DB" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DataSourceConnectionSource"> <dataSource class="com.mchange.v2.c3p0.ComboPooledDataSource"> <driverClass>${db.jdbc.driverClassName}</driverClass> <jdbcUrl>${db.jdbc.url}</jdbcUrl> <user>${db.jdbc.username}</user> <password>${db.jdbc.password}</password> </dataSource> </connectionSource> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %X %ex{short} - %n</pattern> </encoder> </appender>
Note that the properties for username / password / etc are pulled in from another file using the
<property file="_path_to_file/conf.properties" />
All the properties in the external file are being logged which contain passwords etc that do not belong in the logging_event_property table.
I've searched through the manual and the documentation but cannot find a way to disable this behaviour. Any help would be most appreciated!
Cheers,
Bryan