You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <de...@uima.apache.org> on 2015/07/27 23:50:04 UTC
[jira] [Resolved] (UIMA-4533) class cast exception in
CasAnnotationViewer
[ https://issues.apache.org/jira/browse/UIMA-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor resolved UIMA-4533.
----------------------------------
Resolution: Fixed
> class cast exception in CasAnnotationViewer
> -------------------------------------------
>
> Key: UIMA-4533
> URL: https://issues.apache.org/jira/browse/UIMA-4533
> Project: UIMA
> Issue Type: Bug
> Components: Tools
> Affects Versions: 2.8.0SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Fix For: 2.8.1SDK
>
>
> The CasAnnotationViewer has a long-standing issue - it doesn't properly handle the displaying features which are built-in arrays (except FSArray), if the CAS being viewed is a JCas style Cas - a class cast exception happens. This problem predates the changes introduced in UIMA-3374, but is present there too. Prior to UIMA-3374, the CasAnnotationViewer did not activate the JCas, and the DocumentAnalyzer (a main caller of this viewer) always passed in a non-JCas CAS, so things worked.
> The changes in UIMA-3374 activated the JCas (it did a cas.getJCas()), and this exposed these previously present errors which generate class cast exceptions. These errors are caused by code that presumed a non-JCas style of CAS, and did casts that depended on this. One instance of this is the line
> {code}
> StringArrayFSImpl arrayFS = (StringArrayFSImpl) aFS.getFeatureValue(feature);
> {code}
> which generates a cast exception if the JCas is being used.
> Scan the code to find any other instances of an assumption being made of the kind of cover class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)