In a previous post, we explained how you can set up Ctrlflow Automated Error Reporting for your own Eclipse IDE-based products. But of course, you can add automated error reporting to any Java application. This post tells you how, by guiding you through both client-side and server side configuration. First, it tells you how to configure the popular Logback logging framework to send reports to your error reporting server, then it tells you how to configure your server to receive the error reports your applications send.
- Your Java application uses SLF4J + Logback from logging.
- Your application needs to run on Java 8.
If you don’t use SLF4J (the Simple Logging Facade for Java) and Logback, we seriously recommend that you check those out; they are a great solution to many common logging problems.
Ideally, you build your application using Apache Maven or some other build tool (e.g., Gradle, sbt, Buildr) which manages your project’s dependencies and can automatically download them from a Maven repository. But if not (e.g., because you are using plain Ant), you can always download any dependencies manually (see below for download links).
Step 1: Obtaining the Dependencies
First, you need to add any required dependencies to your project.
If you are using Apache Maven, it is sufficient to add the following to the <dependencies> section of your POM:
<dependency> <groupId>com.ctrlflow.aer.client.bundles</groupId> <artifactId>com.ctrlflow.aer.client.logback</artifactId> <version>2.0.0</version> </dependency>
This will automatically download the Ctrlflow Automated Error Reporting Logback client as well as its dependencies from the Central Repository.
If you are using an alternative build tool to download your dependencies, please consult its documentation on the syntax used to declare dependencies in your build file.
If you are managing your dependencies by hand, you will need to download all (transitive) dependencies yourself. For your convenience, we have collected the download links to all required JARs here:
Step 2: Configure Logback
Once all necessary dependencies have been added to your project, you can adapt your existing Logback configuration. So, let’s add a new appender to your logback.xml, which well send all log events logged at a level of “error” to your Ctrlflow Automated Error Reporting server.
<appender name="AER" class="com.ctrlflow.aer.client.logback.AerAppender"> <url>https://aer.ctrlflow.com/example/community/new</url> <productId>org.example.application</productId> <buildId>1.0.0</buildId> </appender> <appender name="ASYNC-AER" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="AER" /> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>ERROR</level> </filter> <neverBlock>true</neverBlock> </appender> <root ...> <!-- Add the asynchronous appender to the root logger. --> <appender-ref ref="ASYNC-AER" /> </root>
You will notice that that above does not add the Ctrlflow Automated Error Reporting appender itself to the root logger; instead, it wraps the Ctrlflow Automated Error Reporting inside an asynchronous appender. This is crucial, as sending error reports to a remote server should not block the logging thread.
If you want to learn more about additional configuration options available for the AerAppender and AsyncAppender, have a look at our full-fledged example hosted at GitHub; it includes extensive comments. And if you require more detailed information on how to configure Logback, please consult its manual.
Automated Error Reporting Server Side Configuration
Let’s assume you are working with a fresh and clean version of the free Ctrlflow Automated Error Reporting service and need to configure it from the ground up. Here is how. If you did not sign up yet, click here…
Sign up now
Step 1: Declare a New Project
Log in into your organization, go to the projects overview page, and click on “New project.” On the next page, enter the common information for your project, i.e., give it a (descriptive) name, a short name, and declare the package namespace this project will be responsible for.
In our example we’ll use “Example Project” as name, “example” as short name, and declare that all error reports that reference classes from org.example or one of its subpackages can be assigned to this project:
Step 2: Configure Server Submission Filters
The Ctrlflow Automated Error Reporting Server allows you to specify filters that decide whether or not an error report it receives is accepted. But if you are using it with a standalone Java application, you typically want it to accept every error your application logs.
Hence, the accepted submissions settings are very simple.
You would only need to configure more complex settings when your organization has both standalone Java applications and, e.g., Eclipse IDE-based products that the Ctrlflow Error Reporting service has to accept error reports from. See this post for more details.
That’s it. Your system is ready to receive error reports from your product.
In case you the setup is not working as expected, check out the integrators FAQ.