[
https://issues.apache.org/jira/browse/UIMA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5056.
----------------------------------
Resolution: Fixed
following Richard's suggestion, added exception if more than 1 nesting switch
for switching class loaders.
> 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: 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)
