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

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

The UIMA extension class loader is one of those which doesn't first delegate to 
its parent (on purpose - for achieving classpath isolation from the caller's 
environment).

So, you can do this.  But then its up to the user of this to insure that code 
which the framework calls is loaded under the proper loader. 

Generally, these things are set up outside of our frameworks - the main 
exception being the Pear classpath isolation.

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

Reply via email to