uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject changing the semantics (very slightly) for JCas objects with respect to Views
Date Thu, 10 May 2007 16:04:02 GMT
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....

For *sofa-aware* annotators, we could use this same approach, but might 
want to give warnings as well.


View raw message