Page History

...

Starting with customization, adding any merged type features

The merged type system (including PEARs) represents the common needed JCas cover class's fields and getters and setters.  Merge this with any customization code while loading the cover class. 

Implementation ideas here JCasClassLoading.

Handling multiple customizations of a UIMA Cas Type

...

1. An aggregate includes two (or more) components, and the classpath for running is set up in such a way that each component's customizations (which would be identically named Java Classes) are in the classpath.
2. An aggregate includes two (or more) components, one (or more) of which is a PEAR, and a type with multiple customizations occurs within the PEAR and outside of the PEAR.  PEARs have their own classpath, and are intended to have their classpath override the containing aggregate's classpath

First, assume there is only one JCas cover class definition.  (PEARs, having their own separate classpath, might have another definition.)

• If there are more than one due to PEARs, 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"

1. .  The "effective" classpath is switched when the PEAR component is entered, and switched back upon exit.

Alternatives for handling Aggregate case (1):

• Do the normal classpath resolution; one definition "wins", according to the rules of Java classpath searching.  This is what is done in current UIMA, for this case.
• Do a full classpath search and locate all the definitions for a class, and do some kind of multiple definition resolution
  • Throw an error, with a descriptive error message
    • allow the person assembling the aggregate to resolve this by excluding all but one (somehow - not defined - maven has some capabilities here)
  • Attempt to "merge" - this seems computationally hard to impossible in some cases.

Alternatives for handling PEAR case (2):

• Use the capabilities input/output: for the case where the particular class in the PEAR is not among the inputs or outputs, just isolate it:
  • switch and use the alternative definition, loaded under a separate class loader used for the PEAR.
  • if an outside-the-pear Feature Structure holds a reference to this - could lead to class-cast exceptions
• Isolate it - switch and use the alternative definition
  • This is what the current UIMA does; suffers from class-cast exception problems
• Throw an error
• Attempt to merge 

 Implementation ideas here JCasClassLoading.

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

...