[
https://issues.apache.org/jira/browse/GEODE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195965#comment-15195965
]
ASF subversion and git services commented on GEODE-1053:
--------------------------------------------------------
Commit f2175524491fcab3206b718d6de0164d4fed8906 in incubator-geode's branch
refs/heads/develop from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f217552 ]
GEODE-1053: Adding "filter" on Function Rest Invoction
Refactoring of RestAPIOnRegionFunctionExecutionDUnitTest.java
RestAPIsOnGroupsFunctionExecutionDUnitTest.java
RestAPIsOnMembersFunctionExecutionDUnitTest.java.
Updating dependency-versions.properties http-core and http-client
> Need support for withFilter in the developer REST API
> -----------------------------------------------------
>
> Key: GEODE-1053
> URL: https://issues.apache.org/jira/browse/GEODE-1053
> Project: Geode
> Issue Type: Improvement
> Components: rest (dev)
> Affects Versions: 1.0.0-incubating.M2
> Reporter: Udo Kohlmeyer
> Assignee: Udo Kohlmeyer
>
> When calling functions through REST API it's not possible to pass a filter.
> The customer would like this ability, as the workaround proposed is
> suboptimal.
> An excerpt from from a John Blum’s email with more context:
> I can confirm that the GemFire Function Execution (DEV) REST API web service
> endpoint
> (https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L112-L245)
> [0] does not support passing filter information.
> As you can see from the execution
> (https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L203-L209)
> [1], there is no...
> Execution function = ...
> ...
> function.withFilter(set).withArgs(args).execute();
> That would require the Spring Web MVC, REST Controller endpoint (POST
> /gemfire-api/functions/
> {functionId}
> ) and handler method, execute(..), to take a Set<String>
> (https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L135-L141)
> [2] parameter for the filter, something like...
> public ResponseEntity<String> execute(..., @RequestParam(value = "filters",
> required = false) Set<String> filter, ...)
> { .. }
> Then the Function Execution would be...
> function.withFilter(filter).withArgs(args).execute();
> Simply passing the filter as part of the Function/Execution arguments will
> not result in GemFire routing the Function execution request based on the
> filter since the filter will be just part of the "arguments" (in the HTTP
> request message body) that are passed to the Function execution. I.e. the web
> service endpoint will not be able to distinguish the "filter" from the
> arguments and there all HTTP request message body contents as arguments to
> the Function.
> -John
> [0] -
> https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L112-L245
> [1] -
> https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L203-L209
> [2] -
> https://github.com/apache/incubator-geode/blob/develop/gemfire-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/controllers/FunctionAccessController.java#L135-L141
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
