[
https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-386.
---------------------------------
Resolution: Fixed
Fix takes advantage of uima-409 restructure. It has the following model: A
CAS, when created, is created with a particular resource manager / class
loader. This is used for all call-outs to user code, unless the user code is
loaded with a different class loader. In that case, prior to calling out to
user code, the generators are switched for JCas (This is done lazily - nothing
is done unless JCas is loaded). The first time this happens, the switch will
load the JCas cover classes using the new class loader, and save the instanceof
FSClassRegistry array contents in a map key'ed by the class loader. From then
on, the switch is just a map lookup followed by a one-word copy, so should be
very fast.
As part of this, we are keeping multiple maps of cas addr -> JCas cover
objects, one per class loader. This allows for better JCas semantics - you
don't lose the objects if someone inserts a Pear in the stream. The clear was
changed to clear all the versions of this.
As part of this update, we found that prohibited CAS functions were not being
disabled in all cases - this was tightened up.
For CAS Multipliers, the getEmptyCAS locks the CAS against prohibited methods
(currently only reset), and switches the JCas to the class loader of the
resource calling this, if needed. It is not switched back until the CAS is
returned via a next() method returning.
> Switching to use correct class loader
> -------------------------------------
>
> Key: UIMA-386
> URL: https://issues.apache.org/jira/browse/UIMA-386
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.1
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 2.2
>
>
> The current design presumes one classloader is used for all components in an
> application. This shows up in the implementation when using JCas - the class
> loader used to load the JCas cover classes is set up in the CAS, and there is
> only one there. This works, unless the analysis engine component is loaded
> by a different class loader. This causes strange class-cast exceptions,
> where the source and target classes look to be identical (what's happening is
> that the classes are named the same, including having the same package names,
> but are loaded with different class loaders). A fix is needed that insures
> the class loader used for JCas can be switched when an analysis engine
> component is run. This should be time-efficient because the flow controller
> could be under a different class loader than the delegates it's controlling,
> so the class loader could be switching back and forth twice per delegate
> dispatch.
> A proposed approach is to add an internal method to the CAS,
> useClassLoader(xxx), which will be called by the framework just before the
> processCas call, passing in the class loader that was used to load the
> analysis engine class. The framework will check to see if this is the
> current in-use class loader, and if it is, do nothing. If it isn't, if the
> JCas is instantiated, it will call a new JCas method, switchClassLoader(xxx).
> This method will (a) reset the cache JCas uses to reduce object creation for
> JCas objects, and do what's needed to load or switch to the right set of
> iterator generators. Where possible, re-loading will be avoided, to make the
> switch fast.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
