uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-5056) UIMA Class loader switching design needs to support more than 2 levels
Date Thu, 01 Sep 2016 17:51:22 GMT

     [ 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)

Mime
View raw message