THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Dynamic - at type system "commit"
- Pros:
- guaranteed exact match, no need for code to check this
- can be done lazily - a large type system with most types unused need not generate most types
- requires a custom class loader (I think)
- Cons:
- user code must commit the type system before any reference to a named JCas type. This "error" can be checked for, if a special class loader is used.
- Pros:
- preexisting - by the user externally, ahead of time, running JCasGen on a fully merged type system
- Pros:
- Maybe less complex
- Cons:
- may be out of sync, need to have more runtime checks
- Pros:
- preexisting at JVM startup time (via -javaagent). This is not practical because
- Cons:
- the merged type system computed might be different - users can write UIMA app code to do custom merging.
- uses one classpath; in embedded apps there may be multiple classpaths.
- is not "lazy" - does whole type system generation
- user requires extra attention when starting a UIMA-based application. Analytics application vendors cannot easily create standalone executable JARs or e.g. Groovy/Jython scripts
- Cons:
What happens when a type system changes?
- CAS reinitialized due to restoring a persisted (binary/serialized) CAS
- New types defined at runtime
- either externally by an application (already possible), or internally by an AE while a pipeline is running (a potential new feature being discussed)
- is JCas the only option or is a basic CAS API still available?
Setup for Type System class loader
...