[
https://issues.apache.org/jira/browse/UIMA-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17145848#comment-17145848
]
Richard Eckart de Castilho edited comment on UIMA-6243 at 6/25/20, 9:25 PM:
----------------------------------------------------------------------------
My understanding is that the CAS shouldn't need to have to know JCas wrappers
at all when it is initially created.
Consider this scenario:
* you have a typesystem.xml file which describes the type system
* you parse this file and initalize a CAS with it
* you call a third-party PEAR from vendor A - the developer of this PEAR has
generated JCas wrappers for the types because she prefers using the JCas
interface. The PEAR creates an annotation of type X using one of these JCas
wrappers
* you call a second third-party PEAR from vendor B - the developer of this PEAR
also liked JCas wrappes and uses them in her PEAR. Because the contract between
the PEARs is defined, in the typesystem.xml file, she tries to access the CAS
and to retrieve type X using her own JCas wrappers
This seems work in UIMAv2 and is a desired property providing for proper
isolation and yet interoperability between the PEAR implementation. Substitute
PEAR for any other mechanism using classloader isolation (e.g. OSGI or the
simulated isolation in the unit test). However, it does not seem to work in
UIMAv3.
was (Author: rec):
My understanding is that the CAS shouldn't need to have to know JCas wrappers
at all.
Consider this scenario:
* you have a typesystem.xml file which describes the type system
* you parse this file and initalize a CAS with it
* you call a third-party PEAR from vendor A - the developer of this PEAR has
generated JCas wrappers for the types because she prefers using the JCas
interface. The PEAR creates an annotation of type X using one of these JCas
wrappers
* you call a second third-party PEAR from vendor B - the developer of this PEAR
also liked JCas wrappes and uses them in her PEAR. Because the contract between
the PEARs is defined, in the typesystem.xml file, she tries to access the CAS
and to retrieve type X using her own JCas wrappers
This seems work in UIMAv2 and is a desired property providing for proper
isolation and yet interoperability between the PEAR implementation. Substitute
PEAR for any other mechanism using classloader isolation (e.g. OSGI or the
simulated isolation in the unit test). However, it does not seem to work in
UIMAv3.
> 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)
