Marshall Schor created UIMA-6047:
------------------------------------
Summary: uv3 deserialization of type arrays could be faulty in
edge case
Key: UIMA-6047
URL: https://issues.apache.org/jira/browse/UIMA-6047
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 3.0.2SDK
Reporter: Marshall Schor
Assignee: Marshall Schor
Fix For: 3.0.3SDK
UIMA has some limited support for typed arrays. These are declared in type
system descriptors by including an elementType specification for a feature
whose range is FSArray.
See
[http://uima.apache.org/d/uimaj-current/references.html#ugr.ref.xml.component_descriptor.type_system.features]
The XCAS and the Xmi serialization forms serialize these as FSArray. The
deserialization code, when deserializing these, looks at the feature
declaration to see if it has an elementType, and if so, changes the type of the
Feature Structure to that type.
This is fine except for two cases:
1) backwards compatibility - this wasn't done in v2. This might be an
ignorable difference (except for utilities that compare CASs, and don't
accommodate this).
2) (more important) Sometimes feature structures are "shared" - that is,
multiple different features might reference the same one. These features might
not have the same element type. A not unusual use case is the one where the
item being referenced is a 0-length Feature Structure, and the code is sharing
one common (immutable) instance of this.
For #2, one possible fix is to examine the "multipleReferencesAllowed" property
of the feature, and only do this narrowing of the type if this is false, and
the rest of the code hasn't accidentally shared this feature structure with
other references.
For #1, perhaps the right approach is to have a backwards compatibility -D flag
that (if set) avoids doing this type update when deserializing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
