Currently, setContext() is called in Resource_ImplBase.initialize(...). However, as illustrated below, there may be multiple calls to "initialize()" as part of a program and they may not even be in the same order as calls to "destroy()".
Now I wonder - would it be more sensible to call setContext() and clearContext() before and after passing control over to client code, e.g. before UIMA calls process() and thus keeping the UIMA context on the thread for shorter periods of time to reduce the risk of overriding it unintentionally / to more reliably re-use it if it is set? E.g. If already a context is set in the thread when Resource_ImplBase.initialize(...), then maybe we should re-use it instead of overriding it? Cheers, -- Richard > On 06.02.2017, at 12:11, Richard Eckart de Castilho <[email protected]> wrote: > > Hi all, > > triggered by changes in UIMA-5058, I have looked again at how the > UimaContextHolder works > and is being used right now. > > In particular, I think the following case is not uncommon but now potentially > problematic: > > ---- > // 1) instantiate reader > CollectionReader reader = UIMAFramework.produceCollectionReader(readerDesc, > resMgr, null); > > // 2) instantiate analysis engine > AnalysisEngine aae = UIMAFramework.produceAnalysisEngine(aaeDesc, resMgr, > null); > > // 3) create a CAS > CAS cas = CasCreationUtils.createCas(asList(reader.getMetaData(), > aae.getMetaData()), > null, resMgr); > > // 4) inform the reader about the type system > reader.typeSystemInit(cas.getTypeSystem()); > > // 5) iterate over the reader using the given CAS and process it using the AE > --- > > The potential problem in this setup is that 1) and 2) both call > UimaContextHolder.setContext(). > > Do you see that as a problem? > > Best, > > -- Richard
