Re: Need a way to limit scanning of deployed jars

2017-01-10 Thread Jacob Barrett
I will echo the need for a modular class loader and the use of an annotation scanner. Those combined will greatly decrease scanning time and dependency nightmares. If you class loader can emit metadata about your classes that can indicated change, like timestamp or hash, then you scanner can also c

Re: Need a way to limit scanning of deployed jars

2017-01-10 Thread Michael Stolz
+1 for deploying all functions and preventing NoClassDefFound error -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Jan 10, 2017 2:19 AM, "Swapnil Bawaskar" wrote: > +1. > > Let's deploy all functions while preventing a NoClassDefFoundError > > On Mon, Jan 9, 2

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Swapnil Bawaskar
+1. Let's deploy all functions while preventing a NoClassDefFoundError On Mon, Jan 9, 2017 at 5:01 PM, Anthony Baker wrote: > > > Normally, I'd respond by saying "well then don't include that Function in > > the jar that you're deploying.” > > > > ^^^ Yep. > > If we need more complicated semant

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Anthony Baker
> Normally, I'd respond by saying "well then don't include that Function in > the jar that you're deploying.” > ^^^ Yep. If we need more complicated semantics than “deploy everything” then we need an application descriptor of some sort. Anthony

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Kirk Lund
If a given Function uses a 3rd party dependency and they don't need to use that Function then I suppose it could save some system resources including PermGen space? Normally, I'd respond by saying "well then don't include that Function in the jar that you're deploying." On Mon, Jan 9, 2017 at 4:

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Kirk Lund
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 e

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Dan Smith
On Mon, Jan 9, 2017 at 4:18 PM, Kirk Lund 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

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Kirk Lund
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

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Jared Stewart
Another alternative might be to use the FastClasspathScanner project (see https://github.com/lukehutch/fast-classpath-scanner and http://stackoverflow.com/a/25354394/3988499 ). This library scans

Re: Need a way to limit scanning of deployed jars

2017-01-09 Thread Bruce Schuchardt
The geode-core test tree has utilities for parsing .class files. The AnalyzeSerializablesJUnitTest uses these utilities to find all DataSerializable classes in a jar or directory. Le 1/9/2017 à 3:22 PM, Kirk Lund a écrit : Please see GEODE-2290 "Provide way to limit scanning of deployed jars"

Need a way to limit scanning of deployed jars

2017-01-09 Thread Kirk Lund
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 F