Contrary to common wisdom it turns out that while the logging mechanism for IBM BPM was moved from log4j to IBM’s standard logging, the log4j jar file itself was not removed from the shipping binaries. This means that you can leverage log4j in your code base if you wish by making some fairly easy changes to your BPM WAS instance.
There is an article on the wiki (found here) that has some recommendations and samples for using log4j, I see a number of problems with this implementation.
- The configuration JS is appears to depend on a global JS variable. This is generally considered a bad idea.
- This implementation depends on a log4j contained as a managed assets. It is not clear to me how the class loader will behave when the same classes are present in different areas of the product.
- All of the above becomes even more confusing and concerning if you are working in a clustered configuration.
Well, as we said, log4j is present in the shipping binaries through the IBM BPM 18.104.22.168 release (
haven’t checked 8.5 yet). Even if you have done nothing to configure it you can confirm this for yourself by opening the process designer and doing the following in a JS Block –
var myLog = Packages.org.apache.log4j.Logger.getLogger('Custom');
Were log4j not available in the WAS class path this would cause a “class not found” exception when you attempted to run the code. If you don’t see a class not found exception, then log4j.jar must be available.
So now the problem becomes one of how to configure log4j to write to the files you want. There are numerous resources to tell you how to create a configuration file for log4j. I’ll attach a sample here later. The final step can be found in this answer on stack overflow. Essentially you can configure WAS to make the location of the log4j file available to log4j by giving an argument to the JVM. You will need to restart WAS but this does work. Make sure the directory where you are logging the files exists. While log4j will create the file if it is not present, it will not create the full path.
Finally if you do find you need to change log4j’s configuration on the fly, you can use the log4j class org.apache.log4j.xml.DOMConfigurator to re-parse the configuration file if you reload it by calling the configure() method with an argument of the file name of the file to use for configuration. I don’t recommend this in a cluster for the same concerns as above, but if in a development environment this would allow you to easily update the log4j file. You might even want to be nice and write a service for use in development that allows people to up/download the log4j configuration file and will make this call on an upload…