Logging Application Incidents using a Log4j Appender

Next to the possibility of reporting incidents over the offered Reporting Adapter, you can report incidents via Log4j using the QueueAdapterAppender. This keeps your code clean from hand crafted incident reporting code but you unfortunately give up the possibility to customize created incident reports with further potentially interesting data that might be helpful for the later debugging as the created incident reports are handled in the background. Nonetheless you can still use a plugin like BugTrap-Enrich to populate the incidents with system properties.

Using the provided QueueAdapterAppender does not change the way BugTrap works - it just gets the necessary incident data from Log4j. You can still configure plugins and choose appropriate distribution channels.

Log4J Configuration Example

Following a sample Log4J configuration that binds the QueueAdapterAppender to the root logger.

log4j.rootLogger=WARN, APPENDERNAME

// the appender
log4j.appender.APPENDERNAME=org.tastybug.bugwerk.bugtrap.base.adapter.log4j.QueueAdapterAppender 

// the name of the monitored project
// (implies the name of the expected configuration file bugtrap-projectName.properties)
log4j.appender.APPENDERNAME.projectName=projectName 

// sets the application component that is used for the incidents 
// .. if it is not set, the loggername is used (which will be 
// trimmed, when its longer than 64 characters)
log4j.appender.APPENDERNAME.applicationComponent=someApplicationComponent

// the layout for the message - choose a different layout, if you like
log4j.appender.APPENDERNAME.layout=org.apache.log4j.PatternLayout

// the message pattern
log4j.appender.APPENDERNAME.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

Next to the necessary configuration of Log4j you still have to provide a configuration for BugTrap (which is described in Direct Logging. By setting the required log4j.appender.APPENDERNAME.projectName=projectName property you tell BugTrap to look for a file named bugtrap-projectName.properties on the classpath which is expected to contain the configuration.

Pitfalls

Despite the given example configuration above it is not a good idea to append QueueAdapterAppender to the root logger, as BugTrap itself uses Log4J for logging purposes which may result in the distribution of incidents that describe BugTrap`s hickups and thus deadlocks. Instead you should declare specific loggers that use the QueueAdapterAppender; have a look at the Log4J documentation to get a picture.