Page History

...

The problem arises because with the Feature Structure data contained solely in a particular instance of a Java class, there must be an approach to have the differing contexts (different PEAR definitions of the customization of the JCas cover class) share and update this data.  An instance produced from a PEAR needs to be able to be used outside of the PEAR, and vice-versa. 

Change approach for customization of JCas to preserve one common system-generated implementation

At the high abstraction level: UIMA is providing

• An externalized representation of a type + features with single inheritance data model 
• The idea that at pipe-line startup, components' individual type definitions are "merged" - allowing types to have the union of all features defined.  This was done to make it easier to develop reusable components that could be independently developed and later assembled together.
• A CAS model where a big collection of these Feature Structures are passed among (separately developed) Annotator components.
• High efficiency (vs some other component models) for accessing this data, including the ability (in JCas) to "customize" the basic create and access fields capability

This idea is to separate the concepts of customizing the JCas cover classes as follows:

• At startup have the system generate from the merged type specifications (this includes types defined or augmented in PEARs) the common merged type system
• Have customization done via hooks to user code.  The customization would need to specify two things: what to hook, and the hook itself.  The hook itself would be a method to run.  What to hook would be a specification (read by the framework at startup time).  The kinds of things that could be hooked are chosen to emulate the current customization capability:
  • Creation of new instances
  • setting / getting of particular Features
• References to Feature Structures would reference the system generated one, which (if customization was active) in turn would call the appropriate hook functions. 
• Multiple different Annotators could have different customizations (something not currently supported). 
• "Boundaries" for where the customizations were active could be established (to mimic a PEAR going in and out of scope).

Copy some Feature Structures into / out of the PEAR

A PEAR represents a packaging and a classpath isolation.  The PEAR may (for some of the shared types) have a different definition of the JCas cover class.  If the difference is simply it has fewer features than the pipeline's fully merged definition, then it can use the main pipeline's definition (it will have extra methods, but those would just go unused).  If it has a different implementation beyond that, then a lazy (when needed) copying of the main pipeline's Feature Structure into the Pear's instantiation would be done.  Likewise, on exit from the PEAR, if the type is mentioned as being an output, and it was "copied" in, then it would be copied out.

• Advantages: 
  • no overhead if PEAR doesn't have customized JCas types.
• Disadvantages:
  • copying of FS in two directions.
  • overhead of remembering what FS need copying-out at exit from PEAR

Needs:

• isStandardJCasClass() to test if the JCas is not customized

...