Yeah, I would expect that FunctionService.getFunction() would return the
same function object I registered with FunctionService.registerFunction.
-Dan
On Wed, Sep 11, 2019 at 12:01 PM Aaron Lindsey <alind...@pivotal.io> wrote:
> Thanks for your response, Dan.
>
> The second scenario you mentioned (i.e. users calling
> FunctionService.getFunction(String)) worries me because our PR changes the
> FunctionService so they would now get back an instance of the decorator
> function instead of the specific instance they registered by calling
> FunctionService.registerFunction(Function). Therefore, any explicit casts
> to a Function implementation like (MyFunction)
> FunctionService.getFunction("MyFunction") would fail. Does that mean this
> be a breaking change? The FunctionService class does not specify that
> getFunction must return the same type function as the one passed to
> registerFunction, but I could see how users might be relying on that
> behavior since there is no other way to get a specific function type out of
> the FunctionService without doing a cast.
>
> - Aaron
>
>
> On Wed, Sep 11, 2019 at 10:52 AM Dan Smith <dsm...@pivotal.io> wrote:
>
> > 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
> > >
> >
>
