[
https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527664#comment-16527664
]
Marshall Schor commented on UIMA-5802:
--------------------------------------
re "significantly complicates the use of the API". There are multiple API's :).
If using plain UIMA (not uimaFIT) APIs, here are some use cases:
# (simplest) no extension class loader. In this case, whatever class loader
loads the UIMA framework is used. Depending on how you start it up, that could
be a thread context classloader (likely perhaps when running as a "servlet"),
but more likely is the application class loader.
# user wants to specify a specific class path to use for uima artifacts. They
create a resource manager, and use one of its APIs to set the extension class
loader:
{code:java}
setExtensionClassPath(String classpath, boolean resolveResource)
setExtensionClassPath(ClassLoader parent, String classpath, boolean
resolveResource){code}
The first setExtensionClassPath creates a UIMAClassLoader whose parent is the
"current" class loader.
* This could be changed to have the parent to the thread's context class
loader if it exists.Is this what you're suggesting?
Or are you thinking of the "simplest" case, where no extension class path is
set? Or, if neither, in which case, what API(s) are you thinking of?
> 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)
