Tools & Consulting for the webMethods® platform

Tools & Consulting for the webMethods® platform

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.

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.

Share:

Facebook
Twitter
Pinterest
LinkedIn

One Response

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.