[
https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16525127#comment-16525127
]
Marshall Schor commented on UIMA-5802:
--------------------------------------
I'm wondering if the uimaFIT code could be changed where it is creating
multiple UIMAClassLoaders to instead create just one, and reuse it? So instead
of
{code:java}
public static class DefaultResourceManagerCreator implements
ResourceManagerCreator {
public ResourceManager newResourceManager() throws
ResourceInitializationException {
try {
UimaContext activeContext = UimaContextHolder.getContext();
if (activeContext != null) { ... }
else {
// If there is no UIMA context, then we create a new resource manager
// UIMA core still does not fall back to the context classloader in all
cases.
// This was the default behavior until uimaFIT 2.2.0.
ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(), "", true);
...{code}
the last line of setting the ExtensionClassPath would look to see if a
UIMAClassLoader with a parent of "ClassUtils.getDefaultClassLoader()" already
exists, and if so, it would use the alternative API for setExtensionClassPath
which is
{code:java}
/**
* Support reusing UIMA Class Loader instances to speed up
* things including the Component Description Editor when
* obtaining info from CustomResourceSpecifiers
* https://issues.apache.org/jira/browse/UIMA-1722
* @param uimaCL -
* @param resolveResource -
*/
public synchronized void setExtensionClassPath(UIMAClassLoader uimaCL, boolean
resolveResource) {{code}
This doesn't create additional UIMA Class Loaders, it just uses the one
provided. It's an "internal" api, not in the normal user ResourceManager
interface.
> 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?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
