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 cache its results through restarts.
As for avoiding scanning or finding functions that the user doesn't want loaded in the deployment I am in the camp of don't deploy it then. Having to define some "external" deployment description to ship along with your deployment to indicate what classes to or not to load is cumbersome. I would argue that such a case is edge at best anyway. Another way to solve this problem is to not instantiate the function, or other deployed resources, until called. The function service would hold a delegate for the function and resolve the true function on demand. First execution would be impacted but overall startup of Geode would stay fast and have a small memory footprint. Now if 100 functions were discovered in the deployment the only thing instantiated would be the 100 very small delegates. On Mon, Jan 9, 2017 at 11:18 PM Swapnil Bawaskar <sbawas...@pivotal.io> wrote: > +1. > > Let's deploy all functions while preventing a NoClassDefFoundError > > On Mon, Jan 9, 2017 at 5:01 PM, Anthony Baker <aba...@pivotal.io> 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 semantics than “deploy everything” then we > > need an application descriptor of some sort. > > > > Anthony > > > > > > > > >
