Page History

Updated 7/2016

This page discusses ideas for supporting JCas customization, and multiple customizations possible due to PEAR classpath isolation with "customized" JCas cover classes.

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. 

The current thinking for PEARs is to support a hierarchy of approaches, from completely general (but slower) where FSs are serialized / deserialized when crossing the PEAR boundary, to optimized approaches attempting to avoid the serialization / deserialization overhead.

A catalog of customizations observed in JCas implementations

Customizations are used for many things; here are some gleaned from some actual use cases:

• Implementations which keep Cas complex objects (e.g. FsLists) in parallel Java data structures (e.g. HashSets).
• Getters which return Java collection objects instead of declared type (e.g. type = FsList, object returned is an ArrayList<FeatureStructure> or a Set<FeatureStructure>)
• Additional "setter" forms.  example: a setter for a float feature, taking a "Float" argument, and handling various NaN style including mapping "null" to one of them, then calling the underlying setter
• Additional methods that operate on multiple fields at once (perhaps keeping them in "sync")
• Override clone to do a deeper copy
• modify a getter - if null is the value, substitute a custom alternative
• Additional arbitrary methods that produce values via operations on features
• Additional constructors, taking more arguments, setting fields
• Additional fields (not in the type system, not serializable, etc.)
• custom tostring methods
• defining a custom compareTo method

...

Multiple customizations can arise when two or more independently developed components both implement customized JCas classes.  This may happen in two ways:

1. An aggregate or custom application includes two (or more) components, and the classpath is set up in such a way that each component's customizations (which would be identically named Java Classes) are in the classpath.  In this case, one of the customizations is ahead of the other in the classpath and will "win" in the class lookup.
2. An aggregate or custom application 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.  The "effective" classpath is switched when the PEAR component is entered, and switched back upon exit.

...

• 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.
• (Not done) 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 messagemessageAttempt to "merge" - this seems computationally hard to impossible in some cases.
    • 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):

• Base case: Assume the worst
  • Assume a successful type system merge
  • Make a class loader for the Pear.
  • At type system commit time for the Pear, use its class loader (and the parent class loader) to load any new JCas class definitions.
    • Type System references back into the loaded classes now need to be conditioned on the Pear environment, to pick the right definition among potential multiples
    • Any new Pear JCas class must become the cover class for any subtypes even if the subtype has a JCas class def in the outer context
    • Instances crossing the Pear boundary need to be serialized/deserialzed or otherwise copied.
• 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 

...