Re: [jira] [Commented] (UIMA-5802) UIMA Class Loader to incorporate Thread context class loader

[br...@shadowridgedev.com]

On 2018-06-29 14:37, Richard Eckart de Castilho (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16528064#comment-16528064
> ]
> 
> Richard Eckart de Castilho commented on UIMA-5802:
> --------------------------------------------------
> 
> Is there some way to avoid duplicating this code everywhere that
> classloaders are used? Would it be an option to make every
> ResourceManager have a UIMAClassloader - i.e. implicitly create an UCL
> which just takes the current CL or the TCL as its parent and use that
> unless the user overwrites by calling `setExtensionClassPath`? Or
> alternatively introduce a method like `getEffectiveClasLoader()` in
> the RM which does what you describe above?
> 
>> 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)