This article describes how to integrate SLF4J logging into the the Stingray event log when using Stingray Java extensions that make use of libraries that use the Simple Logging Facade for Java (SLF4J). The standard SLF4J package includes various jar files that can be used to control logging, such as slf4j-nop-1.7.5.jar that suppresses all messages and slf4j-simple-1.7.5.jar that will output all messages to the Stingray Event Log. By uploading one and only one of these files, you can control whether or not messages are output to the Stingray Event Log. The issue with using slf4j-simple-1.7.5.jar is that it is unaware of Stingray's log levels and logging infrastructure so all messages show up as warnings:
To address this we need to create our own StingrayLogger class that can map log messages to the Stingray log levels. The implementation in this article is based off of slf4j-simple. To create a StingrayLogger class we also need StingrayLoggerBinder, StingrayMarkerBinder, StingrayMDCBinder and StingrayLoggerFactory classes. The source files and jar file are attached to this article. In order to compile these classes yourself, you will need to obtain zeus.java.jar from $ZEUSHOME/zxtm/lib on your Stingray Traffic Manager and slf4j-api-1.7.5.jar. These class files should be in a jar under org.slf4j.impl.
The system property, org.slf4j.stingrayLogger.logLevel, specifies what level of logging to output to the Stingray event log. Any message at that level or higher will be output, any below that level will be suppressed. The value of this property should be one of: "trace", "debug", "info", "warn", or "error". If not specified it defaults to "warn". Stingray doesn't have trace or debug log levels, so any messages at those levels will be mapped to info.
An example of a Java Extension using the StingrayLogger class is described in WURFL - Updated