[
https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526716#comment-16526716
]
Marshall Schor commented on UIMA-5802:
--------------------------------------
yes, the main idea is to set the extension classpath in the resource manager,
like you suggest. One api is:
{code:java}
setExtensionClassPath(ClassLoader parent, String classpath, boolean
resolveResource){code}
The parent would in the use case I thought was common (**Not** the "dynamic"
one) would, at creation time, fetch whatever the thread's context class loader
was, and use it as the parent.
If someone really wants a "dynamic" one, then they should implement their own
class loader that, every time it's trying to load something, dynamically gets
the "current" thread context class loader, and delegates to it.
As I've said before, I don't think this is a realistic scenario, because that
custom class loader could, over time, end up caching loaded classes from all
kinds of different parent classloaders. I'm not seeing a good use case for
this (due, I'm sure, to my lack of adventureful imagination :) )
> UIMA Class Loader to incorporate Thread context class loader
> ------------------------------------------------------------
>
> Key: UIMA-5802
> URL: https://issues.apache.org/jira/browse/UIMA-5802
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.10.2SDK, 3.0.0SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 3.0.1SDK, 2.10.3SDK
>
>
> A long-outstanding request from uimaFIT is to incorporate the Thread's
> context class loader in the uima class loader's lookup scheme. see UIMA-5054
> Doing this would allow uimaFIT to no longer create individual class loaders
> for each AnalysisEngine its factory produces. This would alleviate UIMA-5801.
> Current logic:
> # see if already loaded by this loader, if so return with that
> # try loading it, if succeed, return with that
> # delegate to the parent.
> Fix logic: same except for a step between 2 and 3:
> 2a. delegate to the Thread context class loader (if available), if
> succeed, return with that
> Besides doing this for loading classes, it would also be done for getting
> resources.
> Does anyone see any issues with this approach?
> {quote}It seems this is unneeded; if the thread context class loader is
> wanted in the chain, it should be the parent. The suggested approach seems
> to address a non-issue where 2 parent chains are wanted.
> There are other approaches to prevent multiple class loaders ( and even
> maybe, multiple ResourceManagers) from being created, which might be a better
> solution for UIMA-5801. See comments for this and UIMA-5801.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
