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 > >
