Page History

...

Implementation ideas here in diagram form: UV3 JCasClassLoading.

Handling multiple customizations of a UIMA Cas Type

...

• 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
  • JCas class instance creation for a Pear as a wrapper for the outer instance
    • inner shares the int[] and obj[], has same _typeImpl and _view refs
      • feature updates to one seen by the other, no need to serialize/deserialize
      • parallels the old v2 JCas idea of instance being a cover class to an underlying impl
      • same JCasHashMap lookup from id value, if not found, then generate wrapper
      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 

...