[
https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493575
]
Marshall Schor commented on UIMA-386:
-------------------------------------
The following user code parts are places where the a class loader switch in the
generators may have to occur:
1) calling process(a(J)Cas...) - for a primitive
2) same for an aggregate (calling the computeFlow method to produce a Flow
object
3) Calling newCasProduced on a Flow object
4) calling the Flow object's methods (all methods have access to a CAS)
5) StatusCallbackListener method entityProcessComplete
All of these need checks for class loader changes. Other code that might be
(somewhat) factored and common is:
a) selecting the right "view" to pass
b) selecting if a CAS or JCas is to be passed
c) setting the CAS to disallow certain operations while user code is running
Code done for some of these, probably not factorable:
a) timing and counting
b) recomputing result specifications if type system or result specs change
c) logging
Because many of these may not make use of a generator, we should perhaps
consider a "lazy" initialization - don't do a switch until and unless a
generator is called which would need the switch.
> 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.
