I guess I would then want to separate this into two different requests: 1) prevent NoClassDefFoundErrors by using something like FastClasspathScanner or the utility Bruce mentioned -- we could simply treat the forced load/resolve of every .class as a bug
2) request way to avoid auto-registering every Function in the jar -- this would have to be a GFSH command enhancement (I think) On Mon, Jan 9, 2017 at 4:18 PM, Kirk Lund <kl...@pivotal.io> wrote: > What about this use case: a user has a jar containing 100 Function classes > but only wants the deployer to register one of those, so they would still > need some way to specify which classes to automatically instantiate and > register during the deploy. Right now, it would register all 100 classes. > > > On Mon, Jan 9, 2017 at 3:40 PM, Jared Stewart <jstew...@pivotal.io> wrote: > >> 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 >> >> >
