[ 
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 feature is the ability to use _Gfsh's_ '{{deploy}}' command to 
(re-)deploy JAR files containing 
[Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]
 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|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]
 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.

  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 feature is the ability to use _Gfsh's_ '{{deploy}}' command to 
(re-)deploy JAR files containing 
[Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]
 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_), 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 feature is the ability to use _Gfsh's_ '{{deploy}}' command to 
> (re-)deploy JAR files containing 
> [Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]
>  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|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html]
>  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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to