Page History

...

The UIMATypeSystemLoader has a ref to the committed type system, which is null before a commit.  Type system commit walks up the class loader chain looking for an instance of UIMATypeSystemLoader, and the first one found has its ref changed from null to the committed type system. If it was not null, compare the commited type system with the previous value - if equal, OK, and leave things as is.  If not, throw exception: can't change merged type system using same UIMATypeSystemLoader.

Finding the right class loader at type system commit time

An external App can create a "stand-alone" type system.

• this same type system instance could be used for multiple UIMA pipelines (shared instance)
• It could be created before any CASs and be associated with many CASs eventually
• It could be created after a CAS was created, and replace that CAS's type system (e.g. deserialization)

Type System creation is via new TypeSystemImpl() or one of its callers.  This is a public API, so would like to keep this (for the default case).

• In this case, we have no access to a UIMA Pipeline or CAS in general, so can only look up the classloader parent chain of this internal uima core class instance.
• An alternative is to allow the user to set up a type system loader and pass that to a new version of the type system impl, or to a new version of commit.
  • commit is currently called by CAS.commitTypeSystem(), which also does some work re: the old FsGenerator setups.
  • The call from CAS.commitTypeSystem has (obviously) a ref to a CAS, and therefore, can find the class loader associated with that CAS - the sharedViewData has a JCasClassLoader, set by the createCas calls -> doCreateCas -> setJCasClassLoader.
    • So, from the caller to commit which is via a CAS, we can use that class loader.

Approach - outside of UIMA framework

The UIMA framework could take an approach which says a particular UIMA application (imagine it running as a servlet) has its own classpath, set up and managed outside of the UIMA framework (e.g., by the J2EE servlet APIs).  Using the preexisting alternative, the user would could generate the JCas classes, and include them in the servlet's classpath.  

• drawback - we would need to include some code to verify the loaded class had the right methods and feature range mappings.
• supports lazy loading trivially, but not lazy generation
• restricts particular UIMA app to one type system.

Flow of JCas class generation 

There are two parts:

• generation and loading (done lazily unless no suitable UIMATypeSystemClassLoader in the parent chain, in which case done in batch mode via injection into current classloader)
  • current classloader either JCasClassLoader if one is defined, the thread's context class loader, or the UIMA framework class loader if all else fails
• creation of indirection function interface method handles to use for creation and accessing of features
  • done on first-need, not in batch
  • stored in either the TypeImpl (creation) or the FeatureImpl (set/get of features)
    • The feature ones not needed (and not done) for JCas style access to features by named getters/setters

Content of generated class

...