should UIMA-5802 (incorporate Thread Context Class Loader) also apply to getResource

[Marshall Schor <ms...@schor.com>]

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

Re: should UIMA-5802 (incorporate Thread Context Class Loader) also apply to getResource

[Marshall Schor <ms...@schor.com>]

done, and in the release candidates :-) -Marshall     Jira: UIMA-5802 and UIMA-5902

On 11/6/2018 4:29 PM, Richard Eckart de Castilho wrote:
> On 3. Nov 2018, at 16:17, Marshall Schor <ms...@schor.com> wrote:
>> 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.
> +1
>
>> 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).
> +1
>
> :)
>
> -- Richard

Re: should UIMA-5802 (incorporate Thread Context Class Loader) also apply to getResource

[Richard Eckart de Castilho <re...@apache.org>]

On 3. Nov 2018, at 16:17, Marshall Schor <ms...@schor.com> wrote:
> 
> 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.

+1

> 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).

+1

:)

-- Richard