[ https://issues.apache.org/jira/browse/GEODE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Blum updated GEODE-28: --------------------------- Description: If developers want to "implement" _Apache Geode_ {{Functions}} using [_Spring Data GemFire's_ Function Annotation support|http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#function-annotations], then they are unable to leverage other _Geode_ features as a result. One such features is the ability to use _Gfsh's_ {{deploy}}' command to (re-)deploy JAR files with {{Function}} definitions that may have changed and _Geode_ will "automatically" +detect+ and subsequently +register+ those 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 this is technically a limitation in _Geode_ (and by extension _GemFire_), since _Geode_ only detects _Geode_ specific types (in particular, and +only+... [com.gemstone.gemfire.cache.Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]) class types. While the 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_. So, the right question is, "_what can _Geode_ do to recognize additional types (or rather, meta-data annotated classes identified by _Geode_) that are not part of the _Geode_ core 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. was: If developers want to "implement" _Apache Geode_ {{Functions}} using [_Spring Data GemFire's_ Function Annotation support|http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#function-annotations], then they are unable to leverage other _Geode_ features as a result. One such features is the ability to use _Gfsh's_'{{deploy}}' command to (re-)deploy JAR files with {{Function}} definitions that may have changed and _Geode_ will "automatically" +detect+ and subsequently +register+ those 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 this is technically a limitation in _Geode_ (and by extension _GemFire_), since _Geode_ only detects _Geode_ specific types (in particular, and +only+... [com.gemstone.gemfire.cache.Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]) class types. While the 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_. So, the right question is, "_what can _Geode_ do to recognize additional types (or rather, meta-data annotated classes identified by _Geode_) that are not part of the _Geode_ core 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. > Gfsh's 'deploy' command needs enhancements to recognize Spring Data GemFire > Annotated (deployed) Functions. > ----------------------------------------------------------------------------------------------------------- > > Key: GEODE-28 > URL: https://issues.apache.org/jira/browse/GEODE-28 > Project: Geode > Issue Type: Improvement > Components: functions, management & tools > Environment: Apache Geode with Gfsh > Reporter: John Blum > Labels: ApacheGeode, DeployCommand, Function, Gfsh > > If developers want to "implement" _Apache Geode_ {{Functions}} using [_Spring > Data GemFire's_ Function Annotation > support|http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#function-annotations], > then they are unable to leverage other _Geode_ features as a result. > One such features is the ability to use _Gfsh's_ {{deploy}}' command to > (re-)deploy JAR files with {{Function}} definitions that may have changed and > _Geode_ will "automatically" +detect+ and subsequently +register+ those 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 this is technically a limitation in _Geode_ > (and by extension _GemFire_), since _Geode_ only detects _Geode_ specific > types (in particular, and +only+... > [com.gemstone.gemfire.cache.Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]) > class types. While the 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_. > So, the right question is, "_what can _Geode_ do to recognize additional > types (or rather, meta-data annotated classes identified by _Geode_) that are > not part of the _Geode_ core 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)