[
https://issues.apache.org/jira/browse/UIMA-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421308#comment-15421308
]
Marshall Schor commented on UIMA-5054:
--------------------------------------
This is now fixed under UIMA-5055. The problem is more general: another
failure case would have happened without uimaFIT or the CPE, but just running
ordinary UIMA pipeline with a Pear, where the first accessing of JCas was
within the Pear, and there was a subsequent accessing of the JCas after the
Pear returned to its outer context. I'll check in the fix a bit later since
it's tangled up with updates to CasIOUtils, still needing some work and review
:-)
> 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)
