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

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

Richard Eckart de Castilho created UIMA-3692:
------------------------------------------------

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