You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <ui...@incubator.apache.org> on 2007/04/26 21:02:15 UTC
[jira] Created: (UIMA-386) Switching to use correct class loader
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.
Re: [jira] Commented: (UIMA-386) Switching to use correct class loader
Posted by Adam Lally <al...@alum.rpi.edu>.
On 5/3/07, Marshall Schor (JIRA) <ui...@incubator.apache.org> wrote:
> [ 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
>
I thought of another: When a CAS Multiplier calls getEmptyCas().
Also, we need to be sure to switch the class loader back to the
application's class loader when the processing is complete and the CAS
is returned to the appliation.
> 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
>
Yes, it would be nice to have all this stuff in one place. Right now
I think it is separately in PrimitiveAnalysisEngine_impl,
FlowControllerContainer, and FlowContainer.
> 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.
I agree.
-Adam
[jira] Resolved: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor resolved UIMA-386.
---------------------------------
Resolution: Fixed
Redesigned this to work in multi-threaded environments.
> 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.
[jira] Resolved: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ 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.
[jira] Commented: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493189 ]
Marshall Schor commented on UIMA-386:
-------------------------------------
The view support creates one (or more) CAS objects which are "views" of the base CAS. The JCas support (current design) keeps a set of generators for each view. Thus, the design for this implies loading not just the right set of generators, but repeating this for each view, that was being used by the component. For some components (which are not view-aware) it is possible to load only 2 views (base and the view being used by the component). For view-aware, there is no way to tell (I think) what views it will be using - so the only "safe" thing would be to load generators for all the views.
We might consider changing this design to avoid this issue. One change that would allow using the same generator for all views would require changing the generated JCasGen classes for the ..._Type classes, so the generator code made use of the passed-in CAS view argument. That would impact current users, however, at least requiring them to re-generate their JCas classes. But maybe this isn't necessary, if a good caching design makes loading generator sets fast.
> 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.
[jira] Resolved: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor resolved UIMA-386.
---------------------------------
Resolution: Fixed
> 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.
[jira] Closed: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor closed UIMA-386.
-------------------------------
> 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.
[jira] Reopened: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor reopened UIMA-386:
---------------------------------
Support for switching class loaders is missing for the StatusCallbackListener.entityProcessComplete
> 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.
[jira] Reopened: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor reopened UIMA-386:
---------------------------------
The current support will fail for multiple CASes running from a pool because only one set of generators is in place for the whole pool, and CASes might need different sets. I'm working on a fix.
> 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.
[jira] Work started: (UIMA-386) Switching to use correct class
loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ 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.
[jira] Resolved: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor resolved UIMA-386.
---------------------------------
Resolution: Fixed
> 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.
[jira] Commented: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ 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.
[jira] Reopened: (UIMA-386) Switching to use correct class loader
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor reopened UIMA-386:
---------------------------------
new test case found some problems
> 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.