Details
-
Task
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.10.4SDK
-
None
-
None
Description
The RelativePathResolver_impl can theoretically fall back to the thread context classloader in resolveRelativePath(URL):
URL absURL; if (mClassLoader != null) { absURL = mClassLoader.getResource(f); } else {// if no ClassLoader specified (could be the bootstrap classloader), try the system // classloader // https://issues.apache.org/jira/browse/UIMA-5902 ClassLoader tccl = Thread.currentThread().getContextClassLoader(); absURL = (tccl != null) ? tccl.getResource(f) : ClassLoader.getSystemClassLoader().getResource(f); } return absURL;
However, the default constructor explicitly sets the mClassLoader field:
public RelativePathResolver_impl() { this(null); mClassLoader = getClass().getClassLoader(); // default value, maybe overridden by setPathResolverClassLoader }
This means, unless the classloader is explicitly set to null or unless the non-default constructor is used, it never falls back to the thread context classloader.
My expectation would be that the fallback should be active by default and only if the user explicitly sets a classloader, then it should not happen.
Also, there is no signature of UIMAFramwork.newDefaultResourceManager() which accepts a classloader (or null). One has to create a new ResourceManager_impl(classloader).
Attachments
Issue Links
- is related to
-
UIMA-6240 Failure to resolve type system imports when generating descriptors
- Resolved