uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Resolved] (UIMA-5054) JCas returning generic class instead of JCas cover class
Date Thu, 25 Aug 2016 15:19:20 GMT

     [ https://issues.apache.org/jira/browse/UIMA-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marshall Schor resolved UIMA-5054.
----------------------------------
    Resolution: Fixed

fixed by UIMA-5055. 

> 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
>
> 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)

Mime
View raw message