uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Commented: (UIMA-386) Switching to use correct class loader
Date Fri, 04 May 2007 03:25:15 GMT

    [ 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.

View raw message