[jira] [Commented] (UIMA-3692) Classloading inconsistencies

["Richard Eckart de Castilho (JIRA)" <de...@uima.apache.org>]

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

Richard Eckart de Castilho commented on UIMA-3692:
--------------------------------------------------

[~schor], do you have any comments on this one?

> Classloading inconsistencies
> ----------------------------
>
>                 Key: UIMA-3692
>                 URL: https://issues.apache.org/jira/browse/UIMA-3692
>             Project: UIMA
>          Issue Type: Bug
>          Components: uimaFIT
>    Affects Versions: 2.0.0uimaFIT
>            Reporter: Richard Eckart de Castilho
>            Assignee: Richard Eckart de Castilho
>            Priority: Minor
>             Fix For: 2.0.1uimaFIT
>
>
> The type discovery mechanism relies on Spring tech and eventually on org.springframework.util.ClassUtils.getDefaultClassLoader() which tries the following classloaders:
> * Thread.currentThread().getContextClassLoader()
> * ClassUtils.class.getClassLoader()
> This allows it to override the classloader used for type scanning by setting the thread classloader.
> However, when we actually instantiate components, we rely on UIMA tech which uses:
> * getUimaContextAdmin().getResourceManager().getExtensionClassLoader()
> * Class.forName(annotatorClassName)
> In particular, it does not look at the thread context. 
> To make classloading consistent, it appears that uimaFIT should check if there is a thread classloader and configure it as the extension classloader for UIMA components created via uimaFIT. Because uimaFIT is using mainly static methods, respecting the thread classloader appears to be the most sensible thing. At least better than setting a global classloader.



--
This message was sent by Atlassian JIRA
(v6.2#6252)