uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-5802) UIMA Class Loader to incorporate Thread context class loader
Date Fri, 29 Jun 2018 01:26:00 GMT

    [ https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16527011#comment-16527011
] 

Marshall Schor commented on UIMA-5802:
--------------------------------------

re: comment 3 above (... 3 scenarios ).  One thing to note is that a ResourceManager doesn't
necessarily have an UIMA extension class loader, at all.  It's "optional". 

When you say "fetch the context classloader set" - I think you mean fetch that ClassLoader
(and by implication, any parent chain it has.

A ClassLoader has a "parent", that parent has a parent, etc.  Perhaps this is what you mean
by a "set"?

Once a classloader is installed into the ResourceManager, it is used for all class loading. 
I guess I don't understand the phrase "use/create it once / always".  Once a classloader
is installed into the Resource Manager, it remains there.

Sorry if I've misunderstood...

> 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)

Mime
View raw message