[ https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16528295#comment-16528295 ]
Marshall Schor commented on UIMA-5802: -------------------------------------- I committed this change, to uima v2. Will work on v3 soon. > 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)