Another alternative might be to use the FastClasspathScanner project (see https://github.com/lukehutch/fast-classpath-scanner <https://github.com/lukehutch/fast-classpath-scanner> and http://stackoverflow.com/a/25354394/3988499 <http://stackoverflow.com/a/25354394/3988499>). This library scans classfile binary headers directly to check for classes that implement a given interface or have a given annotation, without actually needing to load the classes that it scans.
> On Jan 9, 2017, at 3:22 PM, Kirk Lund <kl...@apache.org> wrote: > > Please see GEODE-2290 "Provide way to limit scanning of deployed jars" > > Currently if you use the GFSH command "deploy jar" the deployed jar will be > scanned in such a way that the deployer will load and resolve every .class > file in the jar file. The original intention of "deploy jar" was that only > Functions would be deployed. Any .class that is found to be a Function is > automatically registered with the FunctionService. > > You can also include implementations of other Apache Geode callbacks such > as CacheListener. If you then follow up the deploy with "alter region" you > can alter the region to add the CacheListener or other callback. > > Some users have reported trying to deploy a jar with much more than just > Functions or CacheListeners or domain classes used for Region Entries. If > the jar includes a class that the callbacks or domain classes don't > directly use but that class requires a missing transitive dependency, then > the deployer will generate a NoClassDefFoundError when it tries to load and > resolve that class. > > Along with the potential NoClassDefFoundError, forcing every .class to be > loaded and resolved can consume a lot of PermGen memory. > > Various ideas have been tossed around to allow someone to deploy such a jar > without having the deployer generate NoClassDefFoundError. This requires > something like one of the following approaches: > > 1) add a new --do-not-deploy option flag > 2) comma-delimited list of classes to load and deploy > 3) regex list of classes to load and deploy > 4) have I missed something? > > This would give the User better control over which classes to actually load > and resolve. > > -Kirk