[
https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527930#comment-16527930
]
Richard Eckart de Castilho commented on UIMA-5802:
--------------------------------------------------
> In the simplest case, where no UIMA extension class loader is specified, the
>core code could be changed to default to using the thread context class loader
>(if it exists). Is this what you're suggesting?
Yes
> Do you think there would be much (if any) "breakage" of existing UIMA
>applications if this change was done?
I wouldn't expect much breakage. I expect that if there is a context
classloader, it usually defers to the "boot" classloader (I say "boot" here,
but basically I mean whatever the usual classloader in the hierarchy would be
at the given situation - could also well be an application classloader) anyway
if it cannot find the class. So the only thing I would expect is that UIMA
components get access to some additional resources and classes that are
provided exclusively by the context classloader. I believe there could be
breakage in two cases: a) if the context classloader does *not* defer to the
"boot" classloader which could cause UIMA to be cut off e.g. from resources or
even from access to its own JAR or b) if the context classloader provides the
same resources/classes as the "boot" classloader but in incompatible versions.
In either of the two situations, I would believe that there was a problem with
the whole setup to start with. I find it difficult to imagine a situation where
either of the two previous situations would be actually by design. In both
situations, uimaFIT would already have problems today.
> 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)
