On 8/25/2015 8:42 AM, Richard Eckart de Castilho wrote: > On 25.08.2015, at 12:00, Peter Klügl <[email protected]> wrote: > >> The problems are gone... I should learn how to use uimaFIT correctly. Oh >> dear, so much trouble for nothing... >> >> On the other hand, this will not solve my problems when I enforce the >> usage of Ruta as a java library. However, I think I can take care of the >> upcoming problems on the Ruta side of the code, e.g., with the factory >> you mentioned. > @Marshall: would it really be (so) bad to change UIMA to use a Thread > classloader if one is defined?
I vaguely recall some previous discussion about it; see uima.markmail.org and search on thread classloader. A concern I have is that the Thread classloader use is sort of by convention, perhaps depending on the framework you might be embedding into (I'm not an expert here, so please feel free to correct!); because of this, I think UIMA intentionally takes the approach of having this be "outside" the UIMA framework. I think at some point we added an api to allow an embedding to set the class loader to use, and it could of course use the thread local one. > > It might also help if the UIMAClassloader defined an equals method > that could be checked before dumping the JCas cache. +1, sounds like a good idea, if not too hard or slow. -Marshall > The resource > managers are very eager at creating new instances of UIMAClassloader > but they these could well be effectively the same (with the same > parent, same classpath, etc.). > > E.g. although uimaFIT is creating new resource managers, it actually > gives them always the same classloader and the same classpath. But > JCas cannot see this because of the UIMAClassloader that wraps them, > thus it unnecessarily flushes its caches. > > -- Richard
