[
https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on UIMA-386 started by Marshall Schor.
> 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
> Assigned To: 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.
