I have a single threaded application that supports 3rd party plugins. In this architecture, each plugin is loaded by a separate URLClassLoader instance. Once loaded, the application can call the plugin through a pre-defined interface. One problem I'm running into is a plugin that tries to use the
thread's context classloader, which is the application classloader by default, to load a class that meant to be loaded from the URLClassLoader. For example, if a plugin uses the common logging framework, the logging framework uses the thread's context classloader (the app classloader) to load a specific logger class from the CLASSPATH. If the class happens to be in the CLASSPATH, then you'll eventually end up with a ClassCastException, otherwise you'll get a ClassNotFoundException. So the solution would be for either the application or the plugin to set the thread's context loader to the URLClassLoader. However, due to the single threaded nature of the application, my application would have to set the context classloader to the URLClassLoader before calling each pre-defined interface method and reset it to the app classloader after each call. The alternative would be for the plugin to do this when necessary. My question is which of these approaches is the "normally accepted" approach? I know that in an application server, the responsibility usually lies with the applications themselves. But this situation is different because typically each application has its own thread, so they would only have to set the thread context loader only once in the beginning. I would appreciate any insights into this.
Thanks in advance!
