Yes, it seems to me also, that reinitializing a CAS's type system and index definition is unusual, and sort of major surgery. It's not clear to me what happens if this CAS is part of a CAS pool - I suspect things could easily break down because there's an assumption made that all CASes in a CAS pool have the same type system and index definitions.
So - I'm OK with "dropping this" from the API. We're left with: a) needing to pass in a 2nd type system (only - not ts + index def) for supplying the serialized type system to be used for form 6 kind of lenient deserialization. No other format needs this. b) having an anomalous case of the Java Object serialization in CAS Complete Serialization. So - I'm wondering if we can completely drop the CAS Complete Serialization and also perhaps the CASManagerSerializer formats from CasIOUtils? If people want these forms (I'm not sure why they would), they have other APIs to save / load them. This would permit a smaller, easier-to-learn (fewer "exceptions" cases) API for CasIOUtils. Peter, if you're listening, since you originally created this issue - do you need the JavaObject style of serialization/deserialization? -Marshall On 8/11/2016 4:11 PM, Richard Eckart de Castilho wrote: > On 11.08.2016, at 22:04, Marshall Schor <[email protected]> wrote: >> What should a load call using auto-detection, detecting a XMI or XCAS input, >> do >> if the tsiInputStream is not null? >> >> Current impl: tsiInputStream is ignored for XMI and XCAS. >> >> More consistent Impl might be to use read the TSI info and use it to set up >> the >> CAS's type system and index specs. > Well, I have to admit that I was never sure if overwriting the CAS TSI config > is a good idea or not. Probably there are different types of hells to get into > depending on the circumstances one does this. I'm trying to list them in order > > 1) outside a component when a CAS is programmatically created > 2) in a reader > 3) in a multiplier > 4) in an analysis component > 5) in an environment with remote delegates > 6) ...? > > It might be better to completely drop the CAS reinitialization from the load > method for the moment (except when loading SERIALIZED_TSI)... > > ... or to introduce another boolean argument "reinitialize" ... > > ... or maybe a tri-state argument: > > TsiMode.NONE > TsiMode.LENIENT > TsiMode.OVERRIDE > > I think that whenever I needed to have the CAS reinitialized, I have so far > used SERIALIZED_TSI. > > Cheers, > > -- Richard
