The use of third-party Java libraries is a standard requirement for any non-trivial scenario. That applies to plain Java code and just as well to webMethods Integration Server. For this writing we assume that our candidate is Log4j v2. Some kind of custom logging is a standard requirement, so hopefully quite a few people can benefit from this.
Adding jar file to package
The main challenge in our case is that Integration Server already comes with Log4j v2 libraries. So we have basically two options: We can 1) use what is already there, or 2) ship our own version.
The first approach has the advantage that we just need to (or should) set up Designer/Eclipse to be aware of the files, so that code-completion works. But perhaps we want a newer version that comes with additional functionality or bug fixes. So we need to know how to add this.
Where to place the jar file
The jar file needs to go into your package. More precisely into the ./code/jars folder. This means that you can ship a new version whenever needed and have no dependency on what a third party does.
Yes, this also applies if another version of the same jar file comes pre-installed with Integration Server. Whether that file is located in the ./commons/lib/ext folder, in ./IntegrationServer/lib, or a Wm* package doesn’t matter. In either case you put your own, new version into your package.
I have had some discussions in the past about replacing a jar file from the installed product with a newer version. That is a VERY bad idea. Firstly, it will render your installation unsupported. Secondly, there is considerable risk that it will break some functionality. Should someone tell you to do this: Don’t, it is really poor advice.
Classpath
So you have your own new jar file placed into your package. What now? All you need to do is adjust the class loading behavior for the package. There is a somewhat hidden, yet officially supported option to enable a separate class loader for the package. This means that the jar file from the package take precedence over what is already installed in other places.
To do that, you need access to the file system where your package is stored. Open the manifest.v3 file in the package’s root directory. Then insert the following line to enable the package class loader:
<Values version="2.0">
..
<value name="classloader">package</value>
..
</Values>
What this effectively does is “hide” the existing version of the jar file and make use of your file.
What if it does not work?
There are classes that employ some class loader “magic”. This often happens to automatically handle situations. That is a nice idea, but it falls flat as soon as someone wants to do something that was not anticipated.
An examples here is Liquibase, which does not work with the standard approach from above. It would require some very advanced class loader logic. Another case is Apache POI where XML-based files (e.g. *.xlsx) cannot be made to work with recent versions because of a runtime dependency on an XML-related library. Even if you place the required newer version of that XML library into your package, the class loader magic still uses the older one that comes with webMethods. It is an issue far beyond Integration Server and documented in countless threads on Stack Overflow and Reddit.
The bottom line is that you need to get someone involved who has in-depth knowledge on class loader topics.
Use from other packages
A somewhat related topic is making use of the new jar file from another package. You can ensure that your new library is available for e.g. a Java service by adding the required package dependency.
So let’s assume you have created the AcmeLog4j package and now have the AcmeEmail package that wants to make of it. Just make the AcmeEmail package dependant on AcmeLog4j and you are done.
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.
One Response