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