uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Eckart de Castilho (Jira)" <...@uima.apache.org>
Subject [jira] [Comment Edited] (UIMA-6243) JCas returns Annotation when asked for a specific subtype
Date Tue, 29 Sep 2020 18:01:00 GMT

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

Richard Eckart de Castilho edited comment on UIMA-6243 at 9/29/20, 6:00 PM:
----------------------------------------------------------------------------

I am again looking into this issue in the context of UIMAv3 + OSGI.

The PEAR-specific code to hand classloader switches / generators of JCas classes is only marginally
PEAR-specific. In general, it triggers if a change in classloaders is detected. That also
happens in an OSGI context. In fact, the analysis engine / JCas code thinks that it lives
in a PEAR, but instead it lives in an OSGI bundle A while the UIMA framework lives in a bundle
B.

So far so good.

A problem that seems to crop up is that (diagnosis is ongoing):
* the baseGenerators of the JCas are set within the context of bundle B - that bundle doesn't
have access to the JCas classes located in Bundle A, so it creates generators which produce
{{Annotation}} instances for most classes
* when an analysis engine originating from Bundle A is called and the JCas is switched to
the new classloader, it does not install new generators because {{jcci.isPearOverride(cl)
== false}}:
*org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForTypeAndSubtypes(TypeImpl, Map<String,
JCasClassInfo>, boolean, ClassLoader, FsGenerator3[]):*
{noformat}
    // skip entering a generator in the result if
    //    in a pear setup, and this cl is not the cl that loaded the JCas class.
    //    See method comment getGeneratorsForClassLoader(...) in for why.
    if (!isPear || jcci.isPearOverride(cl)) {
      r[ti.getCode()] = (FsGenerator3) jcci.generator;
    }      

------

    boolean isPearOverride(ClassLoader cl) {
      return jcasClass.getClassLoader().equals(cl);
    }
{noformat}
* {{jcci.isPearOverride(cl)}} is false because cl is an {{UIMAClassLoader}} which has as its
parent the bundle A classloader and the classloader for the JCas type in the {{jcci}} is in
fact the bundle A classloader. 


was (Author: rec):
I am again looking into this issue in the context of UIMAv3 + OSGI.

The PEAR-specific code to hand classloader switches / generators of JCas classes is only marginally
PEAR-specific. In general, it triggers if a change in classloaders is detected. That also
happens in an OSGI context. In fact, the analysis engine / JCas code thinks that it lives
in a PEAR, but instead it lives in an OSGI bundle A while the UIMA framework lives in a bundle
B.

So far so good.

A problem that seems to crop up is that (diagnosis is ongoing):
* the baseGenerators of the JCas are set within the context of bundle B - that bundle doesn't
have access to the JCas classes located in Bundle A, so it creates generators which produce
{{Annotation}} instances for most classes
* when an analysis engine originating from Bundle A is called and the JCas is switched to
the new classloader, it does not install new generators because {{jcci.isPearOverride(cl)
== false}}:
*org.apache.uima.cas.impl.FSClassRegistry.getGeneratorsForTypeAndSubtypes(TypeImpl, Map<String,
JCasClassInfo>, boolean, ClassLoader, FsGenerator3[]):*
{noformat}
    // skip entering a generator in the result if
    //    in a pear setup, and this cl is not the cl that loaded the JCas class.
    //    See method comment getGeneratorsForClassLoader(...) in for why.
    if (!isPear || jcci.isPearOverride(cl)) {
      r[ti.getCode()] = (FsGenerator3) jcci.generator;
    }      

------

    boolean isPearOverride(ClassLoader cl) {
      return jcasClass.getClassLoader().equals(cl);
    }
{noformat}


> JCas returns Annotation when asked for a specific subtype
> ---------------------------------------------------------
>
>                 Key: UIMA-6243
>                 URL: https://issues.apache.org/jira/browse/UIMA-6243
>             Project: UIMA
>          Issue Type: Bug
>          Components: UIMA
>    Affects Versions: 2.10.4SDK
>            Reporter: Richard Eckart de Castilho
>            Priority: Major
>
> In a specific classloader topology, a fully initialized JCas with theoretic access to
the JCas wrappers of a given type will not return that type but instead returns an instance
of {{Annotation}}. This leads to an exception like this:
> {code}
> org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator processing
failed.    
> 	at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:427)
> 	at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.innerCall(PrimitiveAnalysisEngine_impl.java:329)
> 	at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:321)
> 	at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
> 	at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:284)
> 	at org.apache.uima.cas.test.JCasClassLoaderTest.thatTypeSystemCanComeFromItsOwnClassLoader(JCasClassLoaderTest.java:126)
> 	... snip ...
> Caused by: java.lang.ClassCastException: org.apache.uima.jcas.tcas.Annotation cannot
be cast to org.apache.uima.cas.test.Token
> 	at java.util.Iterator.forEachRemaining(Iterator.java:116)
> 	at org.apache.uima.cas.test.JCasClassLoaderTest$FetchTheTokenAnnotator.process(JCasClassLoaderTest.java:166)
> 	at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
> 	at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:411)
> 	... 28 more
> {code}
> Looks like this is a UIMAv2 issue only. When running the test against the UIMAv3 master
(commit 0211057ad), I do not get any ClassCastException.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message