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)