Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Mar 23, 2014 — Enterprise Agile Planning expert

Building VersionOne Integrations with Java (Part 3: Logging)

Enterprise Agile Planning
In this part of the series, we’re going to discuss how to make logging an integral part of your integrations. Here’s where we are in this series:As part of a functioning integration, logging can serve many purposes. The most common is that it provides a mechanism for diagnosing and troubleshooting problems. However, logging can also be used to keep a historical record or audit trail, and to provide feedback to users on the integration’s state of execution. When it comes to adding logging to an integration developed in Java, there are a number of options. One is to use the java.util.logging class that is part of the Java API. Another is to use one of the many open source libraries that are available, and a popular and useful one is Apache’s Logging Services, namely the service called log4j. Adding log4j to your application code is fairly straightforward. First you need to add the log4j configurations to your properties file, then you instantiate the logger object in your code to do the logging. Based on the configurations that you are using for the logger, the logging output can be sent to the console window or a file on disk. Here’s an example of log4j settings in a properties file:
# Logger settings.
log4j.rootLogger=ALL, file, stdout

# Log file message settings.
log4j.appender.file.layout.ConversionPattern=%d{yyyy/MM/dd HH:mm:ss} %/5p %c{1}:%L / %m%n

# Log console message settings.
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy/MM/dd HH:mm:ss} %/5p %c{1}:%L / %m%n
There are a few things going on here. The first is setting the rootLogger, which controls which types of messages actually get logged, and it also specifies the appenders that are used to do the logging. The next two sections describe the appenders and how they are used. Of particular interest is the ConversionPattern property that controls the format of the messages that are logged. Once you have the logger setup within your properties file, using it in code is a matter of instantiating the logger at the class level like so:
static Logger logger = Logger.getLogger(YourClass.class);
Notice that you pass the name of your class to the getLogger method. Next you need to tell the logger where to find its configurations, which in this example is the properties contained in the properties file. You do that like this:
Once you have that done, you simply call the logger when you have something that you want logged like this:"Application started...");
The logger supports different types of log types such as TRACE, DEBUG, INFO, WARN, and ERROR, and it is up to you to decide which type to use and when. But what about integrations? Is there anything specific that you should think about logging? The answer is absolutely. Some example of the types of things that you may want to log include:
  • Application initialization
  • User authentication
  • System state when the integration was launched
  • API authorization success/failure
  • API call information such as URLs and query parameters
  • API call responses with status codes
  • And of course, exceptions
Something that you’ll want to spend some time considering is how verbose you want your logging to be, and this is where the different log types can be useful. In the integrations that I have done, I’ll use the INFO type for general process logging, and try to keep them to a minimum. For the next level of logging, I’ll use the DEBUG type to help with basic troubleshooting. For integrations where I will not be able to debug directly on a system, I’ll use the TRACE type to provide a high level of verbosity that customers can turn on, then send me the log file. In the next article, I’ll talk about another basic building block of integrations, and that is data parsing. Data parsing is used when processing the response returned when making call to the VersionOne API, the format of which can be XML or JSON. As always, stay agile my friend…

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us