[
https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261936#comment-13261936
]
Charles de Saint-Aignan commented on UIMA-2391:
-----------------------------------------------
Adam, I see your point about the potential that the system could have enums
representing these values. However, the use of enums in this case makes it
very difficult to extend the system, so I think given that type merging is
possible (and actually necessary for the kind of extension we want to do), it
should exist for string subtypes as well.
Regarding your second analogous case, I don't think it applies since rangeType
is not valid in the case of string subtypes, right?
I think I have found the place in the code where the merging should happen so I
am attempting a patch.
> Uima type merging for string subtypes not working
> -------------------------------------------------
>
> Key: UIMA-2391
> URL: https://issues.apache.org/jira/browse/UIMA-2391
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.3.1AS
> Environment: Linux on Power
> Reporter: Charles de Saint-Aignan
> Priority: Critical
>
> The basic situation is that we are providing a UIMA-based core that other
> teams can extend to suit their needs. As such we are making use of UIMA type
> merging to allow them to add new features to existing types. This approach
> works fine since JCasGen merges the two definitions of the given type and
> produces a superset of the features. This is well documented here:
> http://uima.apache.org/d/uimaj-2.3.1/references.html#ugr.ref.jcas.merging_types.jcasgen_support
>
> However, in addition to this, we have the case where we have a string subtype
> with given allowedValues - lets say values a, b and c. The other team wants
> to extend this type and have additional allowedValues, say value d. Ideally,
> what I would like to do is the following (which follows the pattern used for
> adding features):
> Type Definition #1 (provided by core):
> <typeDescription>
> <name>com.ibm.Type</name>
> <description></description>
> <supertypeName>uima.cas.String</supertypeName>
> <allowedValues>
> <value>
> <string>a</string>
> <description></description>
> </value>
> <value>
> <string>b</string>
> <description></description>
> </value>
> <value>
> <string>c</string>
> <description></description>
> </value>
> </allowedValues>
> </typeDescription>
> Type Definition #2 (extension to core):
> <typeDescription>
> <name>com.ibm.Type</name>
> <description></description>
> <supertypeName>uima.cas.String</supertypeName>
> <allowedValues>
> <value>
> <string>d</string>
> <description></description>
> </value>
> </allowedValues>
> </typeDescription>
> In this case I wanted UIMA to recognize the two definitions at runtime and
> allow the superset of allowedValues. However, this does not do the trick -
> at runtime UIMA throws an exception saying that value d is not an allowed
> value for com.ibm.Type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
