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] [Commented] (GEODE-28) Gfsh's 'deploy' command needs enhancements to recognize Spring Data GemFire Annotated (deployed) Functions.
Date Thu, 21 May 2015 01:00:00 GMT

    [ https://issues.apache.org/jira/browse/GEODE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14553453#comment-14553453
] 

John Blum commented on GEODE-28:
--------------------------------

Technically, there is an "acceptable" workaround to this problem for users/customers that
wish to define Functions using _Spring Data GemFire's_ convenient POJO Function Annotations
combined with using the '{{deploy}}' command in _Gfsh_ to update the Functions.

I intend to verify the solution and then post the details, along with writing a blog post
about the solution for everyone's reference.  But...

Essentially, the solution does not require the developer to bounce the Server where the, otherwise,
SDG-defined Functions are deployed.  Thought, it does require the _Geode/GemFire Server_ to
have been +configured+ and +booted+ with Spring using the Gfsh '{{start server}}' command's
{{--spring-xml-location}} option.

So, in a nutshell, the solution involves..

1. Forgoing the use of SDG Function Annotated POJOs for Function "Definition" (not to be confused
with "Execution") and implementing the user-defined Functions to implement GemFire/Geode's
[Function|http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html].

2. In addition, the custom, user-defined Function must also extend _Spring Data GemFire's_
[LazyWiringDeclarableSupport|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/api/org/springframework/data/gemfire/LazyWiringDeclarableSupport.html]
class.

This class contains logic to "register" itself with the all important and critical [SpringContextBootstrappingInitializer|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/api/org/springframework/data/gemfire/support/SpringContextBootstrappingInitializer.html]
SDG class, which technically allows it to be "auto-wired" by Spring.

For more details on the {{LazyWiringDeclarableSupport}} and {{SpringContextBootstrappingInitializer}}
classes, see the related [section in the SDG Reference Guide|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/reference/html/#gemfire-bootstrap].

So, given the custom, user-defined Function implements a *+required+* Geode/GemFire type (i.e.
{{Function}}), Gfsh's '{{deploy}}' functionality will recognize it, and because the customer,
user-defined Function extends the SDG {{LazyWiringDeclarableSupport}} class, it will be injected
(auto-wired) with other Spring bean dependencies defined in the Spring context, providing
that, again, the _GemFire/Geode_ Server was configured and bootstrapped with Spring.

The user may have to give up some convenience, but they gain the ability to update Functions
using '{{deploy}}'.

Furthermore, you can still call these Function using _Spring Data GemFire_ [Function Execution
interfaces|http://docs.spring.io/spring-data-gemfire/docs/1.6.0.RELEASE/reference/html/#function-execution],
which is arguably the more useful, desired feature in the context of the application.

More details to follow...


> 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" _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],
they are unable to leverage other _Geode_ "features" as a result, such as the ability to use
_Gfsh's_'{{deploy}}' command to deploy JAR files with Function definitions that may have changed
where _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]).
> Therefore, the right question is, what can _Geode_ do to recognize additional types (or
rather, meta-data annotated functions) that are not part of the _Geode_ core types?
> In essence, Goede Gfsh's '{{deploy}}' command needs to be enhanced to recognize SDG-defined
POJO Annotated Functions and act accordingly.



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

Mime
View raw message