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. 

...

Starting with customization, adding any merged type features

First, assume there is only one JCas cover class definition in the class path.  

• If there are more than one, alternatives include: 
  • throwing an error, requiring the user to re-engineer to combine these, (conditioned on the impls being "different")
  • arranging to take just the first one found in the classpath. (Problem occurs when using Pears - the first one may not be discovered until the pear environment is set up).

Then, do a type merge (including Pears), and insert any new feature defs, getters/setters into the class while loading.

This might cover most actual customization scenarios in use today, because today, there's no support for multiple customizations - the first one found in the classpath "wins".

A single common system-generated implementation + an augmentation mechanism for (multiple) customizations

At the high abstraction level: UIMA is providing

...

• 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).

This may be very hard to implement. There are examples of new methods being added in a customization; these methods would need to be called from a base instance (don't know how to do that).  Also, customization may add fields.

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.

...

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

Merge all the custom definitions into one and use that everywhere.

Do some kind of "merge" operation among all definitions of JCas cover classes including those in contained PEARs, and use that one merged definition everywhere.  

• Advantages: is most similar to what we have now
• Disadvantages: it's not always possible to find a merge that preserves all the original implementations.  It might be very difficult to construct an appropriate merge algorithm, given the arbitrariness of the custom code.

Keep the system-generated code in one class, and use a different wrapping class for the customization

Split apart the system-generated (from the merged type system) JCas cover class and user customization, into different classes.  The user customization class would wrap the system-generated one, and create both; all value setting/getting would be via forwarding methods.  

...

• If a JCas cover class is not customized (anywhere in the pipeline, including inside PEAR files), we have the system generated class, and its expected name as it is now.  
• If it is customized, the custom "wrapper" would carry the official name, so users would use it, and the system-generated class would need a new name (e.g. xxxx_UIMA_JCas_Generated.), which would "hide it" from normal access.  A complete analysis of the pipeline running as an application in one JVM would be needed to find (including inside PEARs) which UIMA types had customization (anywhere, including even if in just one PEAR).  Those types would need the alternate naming protocol. 

Keep the system-generated code in one class, and do the customization in a class "extension"

Another way to split apart the system-generated from the customization: have the customization "extend" rather than wrap the system-generated one.

...