Re: why a classloader local to a single JCas instance might be switched, this is only to support PEAR classpath isolation, where the PEAR might have different JCas implementations.
For UIMA v3 I'm thinking of not supporting this, because the Feature Structures in v3 are the JCas classes; switching to other implementations would mean the PEAR couldn't "see" the FeatureStructures. I'm thinking of replacing this with an approach to attempt to merge any JCas classes in the PEAR classpath, with those outside of the PEAR, and have just one definition for the whole pipeline. There's also a thought to allow "local-to-the PEAR" versions of things - this means no data comes in or goes out of the PEAR, for those particular classes. -Marshall On 8/25/2015 4:51 AM, Richard Eckart de Castilho wrote: > 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? > > 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? > > 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 >
