Hi, While debugging problems with UIMA-5802, I realized that we may have missed inserting the thread local class loader for use when UIMA is asked to get a resource (using class loaders).
These things currently use a UIMA class loader if one is defined; if the resource is not found, a null is returned. If there is no defined UIMA class loader, then the lookup is done using the system class loader (used to start the application, typically). One user I've heard is struggling with getting resources to load in different environments - loading works ok when launching from, say, Eclipse, but fails when running in a TomCat server environment, which I think uses Thread Context Class loaders. Here's how it used to work (before UIMA-5802): loading Classes: 1) if the Resource manager exists and has a classloader, use that. If not found, fail. 2) else lookup using the classloader that loaded the UIMA core classes, if not found, fail. loading Resources: 1) if the resource manager exists and has a classloader, use that. If not found, return null. 2) else lookup using the "System" classloader: Classloader.getSystemClassloader; if not found, return null UIMA-5802 inserted (for the loading classes case, only) between 1) and 2), a try with the Thread Context Class Loader; if not found there, it fails. This causes a backwards compatibility issue, which I propose to fix by: if not found there, continue using the classloader that loaded the UIMA core classes. For making loading resources work in contexts like the TomCat and others which use ThreadLocal Context Class loaders, I propose to have those lookups try with the ThreadLocal Context Class Loaders if there is no Resource Manager class loader), and if that fails, to try using the "System" classloader (for backwards compatibility). WDYT? -Marshall
