[GEODE-28] Gfsh's 'deploy' command needs enhancements to recognize Spring Data GemFire Annotated (deployed) Functions.

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Won't Do
• Component/s: configuration, functions, gfsh
• Labels: ClassLoader DeployCommand Function Gfsh deploy
• Assignee: Unassigned
• Reporter: John Blum
• Created: 21/May/15 00:05
• Updated: 20/Apr/18 19:56
• Resolved: 28/Feb/18 15:50

Description

If developers want to "implement" Apache Geode Functions using Spring Data GemFire's Function Annotation support, then they are unable to leverage other Geode features as a result.

One such feature is the ability to use Gfsh's 'deploy' command to (re-)deploy JAR files containing Function classes "implementing" Apache Geode Functions that may have been modified and Geode will "automatically" detect and subsequently register those updated JAR packaged Function(s).

I have been asked, "what is Spring Data GemFire going to do to support the (hot) deploy feature?" However, this is the wrong question.

It is not what SDG can do since, technically, this is a limitation in Geode (and by extension GemFire), and Geode only detects Geode specific types (in particular, and only... com.gemstone.gemfire.cache.Function class types). While non-Function classes and resources are technically added to the "custom" CLASSPATH (defined by an "internal", Geode ClassLoader), there is no recognition and "first-class" support for non-Geode types thereby complicating the matter for technologies that integrate with Geode such as Spring.

So, the right question is, "what can _Geode do to recognize additional types (or rather, meta-data annotated class types) that are not part of the core Geode types?

In essence, Apache Goede's Gfsh 'deploy' command needs to be enhanced to recognize SDG-defined Function Annotated POJOs and act accordingly, in this case.