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)
