https://issues.apache.org/jira/browse/UIMA-5435 fixes the getResources() API of the UIMAClassLoader to look first in its own loader, and then, if not found, to delegate to its parent class loader.
This, it was already doing for classes. I think this is the proper behavior for getResources() too, since the intent is to allow classpath isolation (e.g., used by PEARs), and that should work also for getting resources. But, it represents a behavior change; does anyone know of any cases where this will be an issue? I'm a bit reluctant to add a -Duima.keep_wrong_classloader_behavior_for_uimaclassloader kind of backwards compatible switch if it won't really be needed... Cheers. -Marshall
