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)