I think this would be a viable approach in principle, but it would require us to write a custom classloader implementation for what you have described as the application classloader, rather than simply using an implementation from the jdk.
On Apr 10, 2017 10:30 AM, "Anthony Baker" <aba...@pivotal.io> wrote: What about this: 1) Each jar is deployed into it’s own classloader. 2) If the classloader for jar1 is unable to load a class, it delegates to its parent which can load classes from siblings to jar1. The classloader hierarchy would be: bootstrap << system << application << (deploy jar)* where the application classloader manages the delegation to all deployed jars. Anthony > On Apr 10, 2017, at 10:20 AM, Jared Stewart <jstew...@pivotal.io> wrote: > > There is last one implementation decision for GEODE-2290 that I'm torn about, namely having one classloader for all deployed jars vs having separate classloaders for each deployed jar. > > If we have one class loader, e.g. new UrlClassLoader(jar1, jar2), then: > > - Jar1 will be able to load classes/resources from jar2 (this was the previous behavior of deployed jars with our custom class loader) > - But if we redeploy jar 1, jar 2 will also get its class loader rebuilt, which may raise the likelihood of weird classloader problems arising > > Does anyone else have thoughts about this tradeoff? > > Thanks, > Jared
