(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?