[
https://issues.apache.org/jira/browse/UIMA-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-5164.
----------------------------------
Resolution: Fixed
> 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 snapshot.
> * 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 "UimaSerializable"
> ** _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
(v6.3.4#6332)
