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.
