[
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 "define" _Apache Geode_ {{Functions}} using [_Spring Data
GemFire's_ Function Annotation
support|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/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 "define" _Apache Geode_ {{Functions}} using [_Spring Data
GemFire's_ Function Annotation
support|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/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 "define" _Apache Geode_ {{Functions}} using [_Spring
> Data GemFire's_ Function Annotation
> support|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/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)
