Marshall Schor wrote:
While working on the class-loader switching code, we have revisited an
issue with the way JCas objects work with respect to views.
Currently, for each view, there is a separate set of xxx_Type objects,
a separate set of "cached" cover objects (which are identical to other
view's objects, except that their _Type ref points to the instance for
this view).
This is there only (as far as we can see) to support
aJCasObject.addToIndexes() and removeFromIndexes() which uses this
information to pick the right "view" to use (remember that indexes are
held per view).
Besides inefficiency (replication of objects per view), there is
another side-effect. JCas Objects can, themselves, be extended by
users to hold additional information, other than what's in the CAS.
The current design would create new versions of these objects per
view, so that iterators over different views would get different
instances. So information set into one JCas object in one view would
not be "visible" to instances obtained by iterating using a different
view's index. This could be a documented "feature", or it could be a
"bug".
Because current users seem to often use the aJCasObject.addToIndexes()
method, I want to retain that method, while getting the efficiencies
and fixing the "bug" (if we consider it a bug) above. To do this, we
could make this work as before *for sofa-unaware annotators, only* as
follows: Change the impl of addToIndexes and removeFromIndexes to
reference the "current-view".
Where to get the current-view? First, it needs to be accessable in
several contexts, including the main one (JCas use in an annotator),
but also any other places JCas can be used - which includes
(top-level) application code, call-back routines (which include a
handle to a CAS), and code in flow controllers (which have access to
a CAS). One way I can see to do this is to stick an object
identifying the current-view onto thread-local. Any other
suggestions appreciated....
I realized after thinking about it that we can get the current view from
the base CAS - we always have some CAS pointer in all these objects, and
we can get
to the base CAS, and there is a method getComponentInfo which could be
augmented to return the base CAS. This is probably better than using
thread-local.
-Marshall
