Class FSClassRegistry

java.lang.Object
org.apache.uima.cas.impl.FSClassRegistry

public abstract class FSClassRegistry extends Object
There is one **class** instance of this per UIMA core class loader. The class loader is the loader for the UIMA core classes, not any UIMA extension class loader - **Builtin** JCas Types are loaded and shared among all type systems, once, when this class is loaded. There are no instances of this class. - The type system impl instances at commit time initialize parts of their Impl from data in this class - Some of the data kept in this class in static values, is constructed when the type system is committed The class instance is shared - by multiple type systems - by multiple CASes (in a CAS pool, for instance, when these CASes are sharing the same type system). - by all views of those CASes. - by multiple different pipelines, built using the same merged type system instance - by non-built-in JCas classes, loaded under possibly different extension class loaders PEAR support Multiple PEAR contexts can be used. - hierarchy (each is parent of kind below -- UIMA core class loader (built-ins, not redefinable by user JCas classes) --- a new limitation of UIMA V3 to allow sharing of built-in JCas classes, which also have custom impl, and don't fit the model used for PEAR Trampolines -- outer (non Pear) class loader (optional, known as base extension class loader) --- possible multiple, for different AE pipelines -- Within PEAR class loader - when running within a PEAR, operations which return Feature Structures potentially return JCas instances of classes loaded from the Pear's class loader. - These instances share the same int[] and Object[] and _typeImpl and _casView refs with the outer class loader's FS Timing / life cycle Built-in classes loaded and initialized at first type system commit time. non-pear classes loaded and initialized at type system commit time (if not already loaded) - special checks for conformability if some types loaded later, due to requirements for computing feature offsets at load time pear classes loaded and initialized at first entry to Pear, for a given type system and class loader. At typeSystemCommit time, this class is created and initialized: - The built-in JCas types are loaded - The user-defined non-PEAR JCas classes are loaded (not lazy, but eager), provided the type system is a new one. (If the type system is "equal" to an existing committed one, that one is used instead). -- User classes defined with the name of UIMA types, but which are not JCas definitions, are not used as JCas types. This permits uses cases where users define a class which (perhaps at a later integration time) has the same name as a UIMA type, but is not a JCas class. -- These classes, once loaded, remain loaded because of Java's design, unless the ClassLoader used to load them is Garbage Collected. --- The ClassLoader used is the CAS's JCasClassLoader, set from the UIMA Extension class loader if specified. Assigning slots for features: - each type being loaded runs static final initializers to set for (a subset of) all features the offset in the int or ref storage arrays for those values. - These call a static method in JCasRegistry: register[Int/Ref]Feature, which assigns the next available slot via accessing/updating a thread local instance of TypeSystemImpl.SlotAllocate.
  • Constructor Details

    • FSClassRegistry

      public FSClassRegistry()
  • Method Details