Functions are serialized when you call Execution.execute(Function) instead of Execution.execute(String). Invoking execute on a function object serializes the function and executes it on the remote side. Functions executed this way don't have be registered.
Users can also get registered function objects directly from the function service using FunctionService.getFunction(String) and do whatever they want with them, which I guess could include serializing them. Hope that helps! -Dan On Wed, Sep 11, 2019 at 10:27 AM Aaron Lindsey <alind...@pivotal.io> wrote: > As part of a PR to add Micrometer timers for function executions > <https://github.com/apache/geode/pull/4038>, we implemented a decorator > Function that wraps all registered non-internal functions and adds > instrumentation. This PR is > failing AnalyzeSerializablesJUnitTest.testSerializables because the > decorator class is a new Serializable. > > I'm not sure if it would be OK to add this class to excludedClasses.txt > because I don't know whether this function will ever be serialized. If it > will be serialized, then I'm concerned that this might break backwards > compatibility because we're changing the serialized form of registered > functions. If this is the case, then we could implement custom logic for > serializing the decorator class which would replace its serialized form > with the serialized form of the inner class. Again, I'm not sure if that > would be necessary because I don't know the conditions under which a > function would be serialized. > > Could someone help me understand when functions would be persisted or sent > over the wire so I can determine if this change would break compatibility? > > Thanks, > Aaron >
