[
https://issues.apache.org/jira/browse/UIMA-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor updated UIMA-5056:
---------------------------------
Summary: UIMA Class loader switching design needs to support more than 2
levels (was: UIMA Class loader switching design needs to support more than 2 )
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
