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 2019/01/31 22:19:00 UTC

[jira] [Resolved] (UIMA-5976) uv3 support additional JCas / type system use case

     [ https://issues.apache.org/jira/browse/UIMA-5976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor resolved UIMA-5976.
----------------------------------
    Resolution: Fixed

> uv3 support additional JCas / type system use case
> --------------------------------------------------
>
>                 Key: UIMA-5976
>                 URL: https://issues.apache.org/jira/browse/UIMA-5976
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 3.0.1SDK
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Major
>             Fix For: 3.0.2SDK
>
>
> UIMA allows multiple pipelines having multiple type systems to be run under one single class loader.  Sometimes these type systems have somewhat different versions.  When JCas is used (within one class loader) there can only be one instance of the JCas class definition. The implementation attempts to make variations work, but missed one:
> The following use case is throwing an exception, but should be supported:
> Given: 
>  * JCas class S defining feature F
>  * JCas class T having S as its super class
>  * Type system defining Uima Type S with feature F
> When this is committed, the JCas classes are loaded; and the "slot" for feature F is allocated in S.
> Now have another type system defined with UIMA Type T having feature F, and supertype S.
> This was throwing an exception.  This might occur in practice when a slot is migrated from a subtype to a supertype in some (but not all) instances of type system definitions being run (typically in different UIMA pipelines, running together in one JVM within one class loader).
> Have this work, by setting the slot offset for this type be the slot for F defined in the SuperType S.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)