geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jared Stewart (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-3096) Refactor and unify GFSH http clients
Date Fri, 16 Jun 2017 18:32:00 GMT

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

Jared Stewart commented on GEODE-3096:
--------------------------------------

More historical details from an email thread with John Blum: 

{noformat}
The Javadoc
<https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/SimpleHttpOperationInvoker.java#L33-L34>
[1]
somewhat explains the reason for this, but...

In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
REST service endpoints.

First, are "Well-Known
<https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L143-L294>"
[2] with actual *Spring Web MVC* Controller Endpoints corresponding to each
of the *Gfsh* commands (e.g. `create region
<https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/RegionCommandsController.java#L156-L228>`
[3]).

Then, there is a "Catch-all
<https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L68-L70>"
endpoint [4], which is what the SimpleHttpOperationInvoker
<https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/SimpleHttpOperationInvoker.java#L49>
"invokes" [5].  The idea behind this endpoint was, often times, someone
would add a new command but forget to update the Admin REST API to match,
with "explicit" support (e.g. both this [2] and this [3]) for the new
command.

While this later approach works, it is not highly recommended and is
certainly not very "REST-like", much less "REST-ful".

In fact, the former, "Well-Known" endpoints I setup separately and
individually in order to eventually introduce proper "Resource
abstractions" for each of the REST API service endpoints for each of the
*Gfsh* commands rather than the very use of HTTP Request Parameters to
naively "reconstruct" the Gfsh command-line syntax that is largely still in
place today.  However, I never got that far before the priorities changed.

So, *Gfsh* selects which HTTP-based OperationInvoker to use based on the
availability of the command in the Admin REST API "Index" [2].
{noformat}

> Refactor and unify GFSH http clients
> ------------------------------------
>
>                 Key: GEODE-3096
>                 URL: https://issues.apache.org/jira/browse/GEODE-3096
>             Project: Geode
>          Issue Type: Improvement
>          Components: gfsh, management
>            Reporter: Jared Stewart
>
> We currently have at least two separate HTTP clients used by GFSH over HTTP.  (See SimpleHttpRequester,
AbstractHttpOperationInvoker, RestHttpOperationInvoker, SimpleHttpOperationInvoker).  This
results in a lot of duplicated and inconsistent logic.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message