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