Hi, Am 25.08.2015 um 10:51 schrieb Richard Eckart de Castilho: > Hm... well, if UIMA by default respected the thread classloader as all kinds > of other frameworks, then I guess this would be a non-issue: uimaFIT wouldn't > have to do this ResourceManagerCreator thing. > > So if the classloader is local to a single JCas instance, why does it get > switched while a pipeline is being executed?
Each resource manger in each analysis engine has its own classloader instance. When the analyis engine is called, the classloader of the resource manager is compared to the classloader of the JCas/SharedDataView. Then the instance comparison fails even if the new one is just a wrapper. > How about you rewrite your test using createEngineDescription() and either > SimplePipeline or you create an AAE from your individual engines, instantiate > then and call process() on it once? I added an alternative without uimaFIT where I use xml descriptors. Here, the JCas cover class instances remain. It's not about that the tests fail. The uimaFIT test also is fulfilled since Ruta regenerates the information anyway right now. This is rather a requirement for future development of Ruta. I could restrict the usage of Ruta with a policy like "If you use Ruta with uimaFIT, then you have to create the CAS also with uimaFIT or with the resource manager of the uimaFIT analysis engine..., or it will get really slow when you use it as a java library or you use several separate Ruta analysis engines in one pipeline." If there are other options, I really want to avoid that. I rather prefer to reduce restrictions like getting rid of the type priorities. Best, Peter > Cheers, > > -- Richard > > On 25.08.2015, at 10:31, Peter Klügl <[email protected]> wrote: > >> Hi, >> >> tested it without uimaFIT, works perfectly fine. >> >> Am 25.08.2015 um 10:18 schrieb Richard Eckart de Castilho: >>> You can implement an alternative ResourceManagerCreator that does not set a >>> new classloader and pass it to uimaFIT using >>> ResourceManagerFactory.setResourceManagerCreator() before you run your >>> application. >> I try to avoid such things because all users of Ruta would need to >> remember to do that in their applications. It would just causes problems. >> >>> But why is the classloader that uimaFIT sets not adequate? >> It's adequate, but there is line 4133 in CASImpl: >> >> public void switchClassLoader(ClassLoader newClassLoader) { >> if (null == newClassLoader) { // is null if no cl set >> return; >> } >> if (newClassLoader != this.svd.jcasClassLoader) { >> <- Line 4133 >> // System.out.println("Switching to new class loader"); >> this.svd.jcasClassLoader = newClassLoader; >> if (null != this.jcas) { >> ((JCasImpl) this.jcas).switchClassLoader(newClassLoader); >> } >> } >> } >> >> which causes the drop of all cached JCas cover class instances if the >> class loader instance changes. >> >> Best, >> >> Peter >> >> >> >>> For a bit of history on why this classloader is set, see: >>> >>> https://issues.apache.org/jira/browse/UIMA-3692 >>> >>> -- Richard >>> >>> On 25.08.2015, at 10:13, Peter Klügl <[email protected]> wrote: >>> >>>> Here's what happens: >>>> >>>> uimaFIT creates a new resource manager and sets the extension classpath, >>>> which causes the creation of a new UIMAClassLoader. >>>> >>>> ResourceManager_impl.setExtensionClassPath(ClassLoader, String, boolean) >>>> line: 229 >>>> ResourceManagerFactory$DefaultResourceManagerCreator.newResourceManager() >>>> line: >>>> 62 >>>> ResourceManagerFactory.newResourceManager() line: 42 >>>> AnalysisEngineFactory.createEngine(AnalysisEngineDescription, Object...) >>>> line: 205 >>>> AnalysisEngineFactory.createEngine(Class<AnalysisComponent>, Object...) >>>> line: 281 >>>> StackedScriptsTest.test() line: 43 >>>> >>>> I am not yet sure how we can/should solve this problem... >>>> >>>> Best, >>>> >>>> Peter
