(First up, I know we should be migrating off version 6, and it’s going to happen, but we have to live with it for a while longer; and I suspect this issue persists in later versions of the WM IS anyway.)
Through embedding various open source applications in WM 6.1 packages, I have found that the package-level classloader methods getResource() and getResources() are broken – they fail to find anything. The first method, getResource(), was fixed by SP1, but is broken again by SP2. The second method fails under no-SP, SP1, and SP2. These methods DO work in the global class loader.
This of course wreaks havoc with (for instance) Apache applications that use “discovery” to find resources - typically these are SPIs recorded in META-INF/services/… property files within JARs. The 2 solutions I have used with varying levels of success are to:
-
Explicitly inject the property values, e.g. AxisProperties.setClassDefault(…). This is not always possible.
-
Put the property files on the global classpath. I don’t like doing this as it pollutes the global namespace with private package data, which is especially a problem when different packages use conflicting versions of e.g. xerces.
Options I have avoided so far include:
-
Hack the third-party source code to replace the existing discovery logic with something that works with the WM class loader. This raises maintenance issues, of course.
-
Move these embedded applications into an external JVM process communicating via pipes.
Before I start on options 3 or 4, has anyone found another solution to this class loader problem?