[jira] [Updated] (UIMA-5056) UIMA Class loader switching design needs to support more than 2 levels

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor updated UIMA-5056:
---------------------------------
    Fix Version/s: 3.0.0SDKexp

> UIMA Class loader switching design needs to support more than 2 levels
> ----------------------------------------------------------------------
>
>                 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: 3.0.0SDKexp, 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. 
> After some more investigation and thought, this may not be necessary in normal cases.  This is because the initial CAS JCasLoader value is set to the loader specified when the pipeline is set up, and then only switches when calling Pears, or when calling user code in exit callbacks.  The issue came up previously because one of the exit callbacks was into code loaded by CL#1.  Even in that case, only one level of remembering (to restore the previous class loader) is needed.
> Other cases (somewhat convoluted) may still require a stack implementation.  
> One is nested Pears (not currently supported). Anyone know of other cases?  If not, I'll probably defer this for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)