makes sense to me. This would change the definition of this method, which is new with 3.0.0-beta, so I think there's no backwards compatibility issue.
I'll put up a Jira for this and add it to the beta. -Marshall On 10/3/2017 6:22 PM, Richard Eckart de Castilho wrote: > On 04.10.2017, at 00:00, Marshall Schor <[email protected]> wrote: >> I think I need help in understanding this. AFAIK, there's only one thing a >> resource manager has - an instance of the UIMA Class loader (or not). >> >> I don't understand the different capabilities you refer to. How would you, >> for >> example, set the "resource classloader of the resource manager" without >> creating >> the UIMA Class loader instance? > As a background: what got me thinking about this is the fact that the JCas > registry > tracks JCas classes per classloader. uimaFIT is currently creating new > resource > managers all the time and it may cause the registry to be populated with a > large > number of classloaders. > > That said, the resource managers that uimaFIT creates usually all use the same > classloader. But this is not visible to UIMA/the JCas registry, because every > time the classloader is passed to a resource manager, the RM wraps it in an > UIMAClassLoader. So the reason why the JCas registry ends up with so many > classloaders is the large set of UIMAClassLoader that get created. > > When simply creating a resource manager and configuring it with a custom > classloader, wouldn't it be sensible to not wrap it in a UIMAClassLoader? > > E.g. create a UIMAClassLoader inside the RM for > - setExtensionClassPath(classpath, resolveResource) > - setExtensionClassPath(ClassLoader, String, boolean) > > but not for > - setExtensionClassLoaderImpl(ClassLoader, boolean) > > because in the latter case, no custom classpath is set (this special > capability of the UIMAClassLoader is not used). > > Cheers, > > -- Richard
