Hi Vahram, I'm not entirely clear what your use case is. Are you asking for an official java API which mimics the "gfsh deploy command"?
--Jens On Wed, Oct 25, 2017 at 5:54 AM, Vahram Aharonyan <[email protected]> wrote: > 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 >
