[
https://issues.apache.org/jira/browse/UIMA-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996664#comment-14996664
]
Marshall Schor commented on UIMA-4687:
--------------------------------------
Sure, but I think there might be a better / more general approach.
I see two variants - one which starts with an instance of a JCas class, and one
which starts with the JCas class itself.
Given an instance, you can easily and directly get to the UIMA Type system impl
for that type, using {{ my_instance._typeImpl }}.
The TypeImpl has methods like getName() to get the name, and you can also get
all the features defined for that type as well.
For the case where you are starting from a Class, since that same class could
be in use in multiple type systems, you need to have a reference to the type
system. Then the lookup goes like this:
*
{{typeSystemImpl.getJCasRegisteredType(reflected_value_of_classes_typeIndexID)}}
Would this satisfy the use cases? If not, please say more about the use cases
:-)
> UV3 improve JCas feature id use for index corruption checking and journaling
> ----------------------------------------------------------------------------
>
> Key: UIMA-4687
> URL: https://issues.apache.org/jira/browse/UIMA-4687
> Project: UIMA
> Issue Type: Sub-task
> Components: Core Java Framework
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> When setting (changing) values for features, sometimes index corruption
> checking needs to be done, and sometimes changes need to be journaled. Both
> of these need to identify the feature involved. This operation should be
> fast and memory-cache-friendly (e.g. not involve following a long chain of
> dereferencings).
> Add static final fields that represent features used by a particular JCas
> class, which have names derived from the short-feature-name, and won't
> collide with other names, and set these using the same JCasRegistry mechanism
> to unique values within a class loader. This allows the same JCas cover
> classes to be used with different type systems.
> Change the corruption testing logic to use BitSets and have a version which
> uses these indexes as well as one which uses the FeatureImpl featureCode.
> Keep one extra table mapping these codes to FeatureImpls, per type system.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
