You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2016/08/14 14:29:20 UTC
[jira] [Created] (UIMA-5056) UIMA Class loader switching design
needs to support more than 2
Marshall Schor created UIMA-5056:
------------------------------------
Summary: UIMA Class loader switching design needs to support more than 2
Key: UIMA-5056
URL: https://issues.apache.org/jira/browse/UIMA-5056
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Affects Versions: 2.8.1SDK
Reporter: Marshall Schor
Assignee: Marshall Schor
Priority: Minor
Fix For: 2.9.0SDK
A recent Jira UIMA-5054 highlighted a potential use case not previously adequately considered:
* classloader - application - loads the "main" (under CL#1)
* main instantiates a UIMA pipeline, specifying an extension class loader (CL#2)
* UIMA pipeline contains a Pear, specifying its own class loader (CL#3).
JCas class may be used by code loaded under any of these 3 class loaders. In the example in UIMA-5054, a component called by the UIMA Framework was loaded under CL#1, so the framework needed to "switch" to this. Had that component been inside a Pear, it would need to switch to CL#1 from CL#3, and then restore CL#3 when returning from the component back to the UIMA Framework. But the current design for switching only supports 2 (not 3 or more) levels of switching / restoring.
Extend this to support arbitrary levels, using some kind of a stack mechanism. Two things need extension: support for tracking the current JCas class loader, and support that tracks the current JCasHashMap instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)