Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

One of the most widely used frameworks for logging is Apache Log4j. It is also used by various webMethods components, incl. Integration Server. While that gives re-assurance about its reliability, it also makes it a bit more complicated to run your own logging next to what comes out-of-the-box.

This article discusses options and demonstrates how you can run your own logging in a non-intrusive way.

The "common" approach

Log4j comes with a lot of convenience functionality. This makes its use easier in the situations that have been anticipated. On the other hand, such convenience is always a two-egded sword. Once you leave the trodden path, things often get a bit more complicated. In addition, almost all the tutorials you can find online (at least when I last looked) come with a lot of assumptions that don’t fit Integration Server.

The consequence is that most recommendations I have seen are basically about “extending” the existing logging. They describe how to change (configuration) files that have been installed by the webMethods Installer. It basically boils down to adding your own logger. You can of course do this, but it comes with a number of downsides.

  • You may end up with a system that is not supported any more.
  • If done wrong, your changes will affect the out-of-the-box logging. There is a risk to loose messages.
  • The next fix installation may remove your changes, so you need to re-apply them again. Then you have to test if they still work with the fixes installed.
  • The fix installation can fail. If a script makes assumptions about what is in certain configuration files, manual changes from your side can break things. Hopefully not in a “silent” way so that you only notice days later, when data has already been lost or compromised.

So in a nutshell I strongly advise against this approach. It may work, but comes with unnecessary work and operational risk. Please read on about a much cleaner approach.

Running your own logging instance

The easiest way out of the problems with leveraging the existing Log4j instance, is to not use it at all. You can relatively easily run your own instance and I will show you how.

It boils down to some Java code in the form of a POJO. You can even make it work with Java services only, but that is a way I generally discourage for anything but simple wrapper logic. Details in this LinkedIn post.

The big difference to what is usually done is the explicit initialization and loading of the configuration file. Below is a simplified code snippet that shows the approach.

				
					File log4jConfigFile = new File("/path/log4j2.xml");
		
ConfigurationFactory factory =  XmlConfigurationFactory.getInstance();
ConfigurationSource configurationSource = null;
try {
    configurationSource = new ConfigurationSource(new FileInputStream(log4jConfigFile));
} catch (IOException e) {
    e.printStackTrace();
}
Configuration configuration = factory.getConfiguration(logCtx, configurationSource);

logCtx = new LoggerContext("MyPackage");
logCtx.start(configuration);

Logger logger = logCtx.getLogger("MyLogger");
logger.log(INFO, "My test log message");

				
			

The code above, while generally working, leaves out a few things. For a more comfortable starting point, please have a look at this GitHub repository. It contains a working Integration Server package (download installable ZIP file) that you can use as a starting point.

As the Log4jDemo package shows, you can even use the Log4j jar files that come with webMethods. If you want to be independent when it comes to shipping updates, which I recommend, you can have your own jar files in your package and use the package class loader (details can be found here).

If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.

© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.

Share:

Facebook
Twitter
Pinterest
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

On Key

Related Posts

Custom logging with Log4j on Integration Server

Every serious IT system needs proper logging. This article describes how I use Log4j v2 with webMethods Integration Server. There is no need to change anything on the system, just install the package and it works.

External Java libraries in webMethods Integration Server

To get most out of your Integration Server you will sooner or later need to leverage the functionality of existing Java libraries. Common examples are Log4j or Apache POI (for working with Excel or Word files). Here is a short guide for this.

Running webMethods Integration Server in containers

Organizations are moving from traditional deployments to containers and Kubernetes to increase business agility. This article discusses a lot of topics that are relevant to actually reach the goal of faster delivery of value to the business through software. Because if you do it wrong, you just end up with yet another technology stack. And, as always, technology is not your biggest challenge.

Legacy software: Better than its reputation

Moving away from “legacy software” is easier said than done. It is a complex combination of business and technical aspects that needs to be looked at.

Having worked on a number of migration projects over the last 20 years, here are my thoughts. It is just a “short” overview but will give you a starting point for things to look at.