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

Reply via email to