IBM BPM and Log4J

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.

1. The configuration JS is appears to depend on a global JS variable.  This is generally considered a bad idea.
2. 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.
3. The initialization of log4j in this solution is done in Javascript.  It is unclear to me what would happen if 2 different Process Apps tried to initialize log4j in this case, especially if the values conflicted.  Ideally each would have its own log4j writing to its own files, but I’m not sure the behavior would be by design or by happenstance of what a random developer did.
4. All of the above becomes even more confusing and concerning if you are working in a clustered configuration.

So, the question becomes “If I want to use Log4j to be able to log to specific files either from Javascript or my Java integrations how can I do it?”

Well, as we said, log4j is present in the shipping binaries through the IBM BPM 8.0.1.1 release (haven’t checked 8.5 yet and in 8.5 as well).  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…

UPDATE 8/20/2013: Further experimentation has shown that if you call the DOMConfigurator, the results are additive if there is no overlap between the old configuration and the new. This means multiple configuration files will only affect one another where either the logger or appender entries have the same name.