[
https://issues.apache.org/jira/browse/UIMA-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419363#comment-15419363
]
Marshall Schor commented on UIMA-5054:
--------------------------------------
I'm ignoring that NPE for now, and proceeding to work on the initial issue. It
appears that this is what is happening:
1) There are two class loaders set up:
* the initial one which is the basic standard default Application class loader
used for launching the "main".
* a second class loader is set up (surprisingly, not sure where/why) which is a
UIMAClassLoader, probably when the CPE pipeline is set up.
The definition of the code run as the StatusCallbackListener is in the
MinimalExample. This is the class "CustomStatusCallbackListener", and it is
loaded by the classloader # 1 (this is important).
The code in the CPM which calls user code is switching to classloader # 2
normally. The JCas classes are defined on the first creation of JCas, which
happens when the process method is called (under classloader #2)
But the code in the CPM which calls the CallbackListener is switching to the
classloader used to load the "CustomStatusCallbackListener", which is, of
course classloader #1 - this classloader doesn't have the JCas classes loaded
by UIMA, and in fact the references to them will be to different loaded Class
definitions (very bad and confusing).
The fix is to do a better setup of class loaders. I think in this example,
there should be no UIMAClassLoaders being instantiated. I haven't yet tracked
down where / why this is happening. That's the next thing to track down.
> JCas returning generic class instead of JCas cover class
> --------------------------------------------------------
>
> Key: UIMA-5054
> URL: https://issues.apache.org/jira/browse/UIMA-5054
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.8.1SDK
> Reporter: Richard Eckart de Castilho
> Fix For: 2.9.0SDK
>
>
> A DKPro Core user reported that when deploying an AE in a CPE
> he was unable to access a JCas cover class in the
> entityProcessComplete(...) CPE callback. See:
> https://groups.google.com/d/msg/dkpro-core-user/-DtO5Ivnk9I/sjQAPPv1BwAJ
> {noformat}
> public void entityProcessComplete(CAS cas, EntityProcessStatus
> status) {
> try {
> JCas jcas = cas.getJCas();
> // here getting a JCas cover class fails. Instead,
> // an AnnotationImpl is returned from the jcas.
> } catch (CASException e) {
> e.printStackTrace();
> }
> }
> {noformat}
> The problem appears to be that the static CAS classloaders are restored
> *before* invoking the entityProcessComplete() callback (CPMEngine 3468):
> {noformat}
> try {
> if (null != cas)
> ((CASImpl)cas).switchClassLoaderLockCas(statCL);
> statCL.entityProcessComplete(cas, eps);
> } finally {
> if (null != cas)
> ((CASImpl)cas).restoreClassLoaderUnlockCas();
> }
> {noformat}
> Is there any reason that the classloaders are switched out before invoking
> the callback? If not, any objection if I change the code such that the
> callback is invoked before the classloaders are switched out?
> {noformat}
> Thread [[Procesing Pipeline#7 Thread]::] (Suspended (breakpoint at line 1021
> in CASImpl))
> CASImpl.setLocalFsGenerators(FSGenerator<FeatureStructure>[]) line:
> 1021
> FSClassRegistry.swapInGeneratorsForClassLoader(ClassLoader, CASImpl)
> line: 225
> JCasImpl.switchClassLoader(ClassLoader) line: 548
> CASImpl.switchClassLoader(ClassLoader) line: 4195
> CASImpl.switchClassLoaderLockCasCL(ClassLoader) line: 4183
> CASImpl.switchClassLoaderLockCas(Object) line: 4176
> CPMEngine.callEntityProcessCompleteWithCAS(StatusCallbackListener, CAS,
> EntityProcessStatus) line: 3472
> ProcessingUnit.doNotifyListeners(Object, boolean, EntityProcessStatus)
> line: 1650
> ProcessingUnit.notifyListeners(Object, boolean, EntityProcessStatus)
> line: 1592
> ProcessingUnit.processNext(Object[], ProcessTrace) line: 917
> ProcessingUnit.run() line: 575
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
