Hi, Currently we are facing issues with letting Geode to know about our java plugins that are being loaded on distributed system members during runtime. Jira story about this is opened by us recently - GEODE-3904. Just posting here to understand if others have hit this kind of issue or to have additional thoughts that can help us addressing this issue.
Specifically, our issue occurs when we try to perform some action that causes serialization/deserialization of objects that are instance of classes coming from plugin JARs. To successfully complete these operations Geode need to have this plugin jars/classLoaders in its ClassPathLoader. In Geode versions prior to 1.2.0 it was possible to achieve this goal by invoking internal ClassPathLoader#addOrReplaceAndSetLatest API. This piece of code was removed in 1.2.0 as a part of ClassPathLoader changes to rely on single URLClassLoader. After this change alternate way to update Geode class loaders is to deploy plugin Jar but this does not seem to be possible due to the following: 1. Per documentation, clean way for user to deploy a JAR is only with usage of gfsh. There is no public API that allows user programs to perform JAR deployment runtime once cluster/member startup is already finished. 2. With usage of internal API (org.apache.geode.internal.JarDeployer#deploy(java.lang.String[], byte[][])) it seems that org.apache.geode.internal.ClassPathLoader#classLoaderForDeployedJars is getting overwritten with every deploy attempt. Hence it is not possible to invoke this internal API in user application multiple times to load different jars and classloader to GEODE classPathLoader on the fly. 3. For dynamic plugging of jar it is enough just to add corresponding classLoader to Geode ClassPathLoader, hence required classes will be loaded once needed and it is not necessary to have another copy of that JAR in deployment directory, keep versioning of that and afterwards take care of undeploying it to release consumed resources. So we think that giving some API to user that will allow to dynamically load/unload specific ClassLoader to ClassPathLoader will address this issue. Could anyone please kindly share his thoughts on this? Thanks, Vahram
