[jira] [Commented] (UIMA-5054) JCas returning generic class instead of JCas cover class

["Marshall Schor (JIRA)" <de...@uima.apache.org>]

    [ https://issues.apache.org/jira/browse/UIMA-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418944#comment-15418944 ] 

Marshall Schor commented on UIMA-5054:
--------------------------------------

The logic for switching classloaders is meant to apply to the Pear constructs, and be mostly a no-op in other cases (because it can be costly to swtich, and there's in general no need to do any switching, unless entering / exiting PEAR class-path isolation contexts).

Are Pear's being used in this case?  If not, I wonder what's causing a none-no-op switching to happen?

If Pears are being used, then perhaps a more general fix is needed - one which does this switching at all the points between the framework and user code the framework calls which could contain user JCas class references.

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