Uploaded image for project: 'logback'
  1. logback
  2. LOGBACK-399

DBAppender merging properties

    XMLWordPrintable

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • 0.9.29
    • logback-classic
    • None
    • ubuntu linux 11.04, java 16, intel processor

    Description

      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.

      --------------------------------------

      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,

      Attachments

        Activity

          People

            logback-dev Logback dev list
            bryanward Bryan Ward
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: