geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Blum (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GEODE-28) Gfsh's 'deploy' command needs enhancements to recognize Spring Data GemFire Annotated (deployed) Functions.
Date Thu, 21 May 2015 19:26:18 GMT

     [ 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)

Mime
View raw message