Yes, uimaFIT should not create a resource manager, or at least there should be an option to reuse a given one... or at least a given classloader. The switching is somewhat problematic for me and Ruta, but did not cause too serious problems yet.
There is of course ResourceManagerFactory.setResourceManagerCreator(). With this, I could delegate the existing/ruta resource manager to the uimaFIT factories, but I do not know if I should really do this in a static manner. I do not know if we should/need support multiple levels of nesting. What are our options concerning the three projects? The functionality in ruta calling analysis engines is needed (preferable without switching in future). The next uimaFIT release is not planned yet, right? If we keep the exception in uimaj before the switching is addressed in uimaFIT, then I have a serious problem in Ruta. Best, Peter Am 19.08.2016 um 07:53 schrieb Richard Eckart de Castilho: > Hm, I think this could also be addressed via the UimaContextHolder that was > discussed elsewhere. uimaFIT could check if there is an active context > and re-use its resource manager instead of creating a new one. > > What do you think? > > Cheers, > > -- Richard > >> On 18.08.2016, at 23:16, Marshall Schor <m...@schor.com> wrote: >> >> Some other things to consider: >> >> The way Ruta is using uimaFIT in the failing case results in multiple >> analysis >> engines created with different resource managers, but the CAS from one is (I >> think - didn't check this...) sent through the AE of another. >> >> When multiple AEs are used this way with a common CAS, then the type system, >> type priorities and indexes definition associated with this common CAS are >> used. >> So it makes sense to share these parts of the Resource Manager. >> >> And, if the intent is to have JCas cover classes produced by one of the AEs >> usable by the other AEs, then there should not be extra UIMA Class loaders, >> and >> class loader switching. This is because one of the things that class loader >> switching does is to swap in/ out different JCasHashMaps. These are maps >> that >> associated already created JCas instances with specific Cas Feature >> Structures. >> This could be important, if the JCas instance was carrying along extra >> information (not in the CAS) that you wanted shared with other >> class-loading-contexts (e.g., an "outer" AE, or an "application"). >> >> -Marshall
