uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Updated] (UIMA-5164) uv3 support for arbitrary Java objects in the CAS
Date Tue, 01 Nov 2016 03:42:58 GMT

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

Marshall Schor updated UIMA-5164:
    Component/s:     (was: e)
                 Core Java Framework

> uv3 support for arbitrary Java objects in the CAS
> -------------------------------------------------
>                 Key: UIMA-5164
>                 URL: https://issues.apache.org/jira/browse/UIMA-5164
>             Project: UIMA
>          Issue Type: New Feature
>          Components: Core Java Framework
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>            Priority: Minor
>             Fix For: 3.0.0SDKexp
> Using JCas, it has been possible to have arbitrary Java objects included in the Java
instance.  The problem with doing this has been that there was no architected way for these
objects to participate in the broader UIMA interoperability concepts such as serialization,
remote annotators, etc.  And, furthermore, JCas objects were optional, and might not be used.
> UIMA V3 implements Feature Structures in the CAS as JCas objects directly, so these are
now always present and reliable.  This means that when an implementation adds arbitrary Java
objects (e.g, a special HashSet containing Feature Structures) to a JCas class definition,
they are reliably present.
> Here's how we could make this all work in v3.
> A user would first pick some Java class to emulate in the CAS.  A requirement would be
that the data in the emulated class would need to support having a serialized form representing
a  "snapshot" of the data at a particular moment, that  could be put into the CAS using a
fixed number of UIMA features of normal UIMA data types, including Feature Structures.  For
example, an ArrayList<FeatureStructure>  could be put into the CAS as an FSArray instance
of the current size; a Map<Integer, FeatureStructure> could be put into the CAS as an
IntegerArray and an FSArray, etc.  The snapshot would be produced whenever needed, for example,
during serialization.  A corresponding transformation (used, for instance, during deserialization)
would convert the snapshot data back into the emulated Java class instance.
> This new kind of hybrid object would be implemented with a custom JCas cover class which
wrapped the emulated Java class instance.  It would also have as features those needed for
the "snapshot" representation.
> The user would need to 
> * define a UIMA type; this type would include the feature definitions needed for the
> * create the corresponding JCas cover class for that type
> * add 3 extra methods in the cover class, all methods defined by a new UIMA interface
> ** _init_from_cas_data()
> ** _save_to_cas_data() 
> ** clone
> The _init_from_cas_data would use the cas data in this Feature Structure to initialize
the emulated Java class.  
> This method would be called by the framework whenever it makes a new instance with non-empty
Feature Structure data (for example, during deserialization), so that the emulated Java class
instance may be initialized.  This would typically be called by routines like the cas copier
and deserialization.
> Similarly, the _save_to_cas_data would be called by the framework as part of serialization,
and would extract data from the emulated Java class and save as CAS features..
> This Jira adds support for this approach; other Jiras will add some likely popular new
types (example: FSArrayList - like ArrayList<TOP>).  Users can (easily ?) add types
of their own, for instance, if they need a peculiar kind of Set of Feature Structures, perhaps
built on top of ConcurrentSkipListSet using a special definition of set-member-equals.

This message was sent by Atlassian JIRA

View raw message