[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16388413#comment-16388413
]
John Blum commented on GEODE-4787:
----------------------------------
To help with testing and CI efforts, I have created a _Spring Data for Apache
Geode_ Integration Tests that properly tests that a {{ClientCache}} application
can properly create a required _Region_ in server cluster (e.g. PCC) and
subsequently access the required _Region_ (i.e. perform basic data access
operations like CRUD and querying).
The test class ("`ClusterConfigurationExampleIntegrationTests `" is
[here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java].
It relies on the
[`example.test.client.model.Customer`|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/model/Customer.java]
application domain object and corresponding
[_Repository_|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/repo/CustomerRepository.java].
Files attached for convenience.
The test is an _Spring (Data Geode)_, Apache Geode {{ClientCache}} application
([here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/repo/CustomerRepository.java])
that enables the [_Cluster Configuration
Push_|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L81].
The test goes on to
[assert|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L66-L78]
that data can be accessed in the "_Customers_" _Region_.
It is real simple to adjust the {{Pool}} port that the {{ClientCache}} uses to
connect to the cluster by setting both or either the
{{spring.data.gemfire.locator.host}} and/or
{{spring.data.gemfire.locator.port}} properties as System properties
([here|https://github.com/jxblum/contacts-application/blob/master/cluster-configuration-example/src/test/java/example/test/client/ClusterConfigurationExampleIntegrationTests.java#L89-L90]).
Both properties default to "localhost" and the default Locator port, "10334",
by default.
This test class, with the right dependencies should be able to be included the
Apache Geode test suite.
NOTE: the _Spring Data Geode_ dependency only need be a "test" dependency to
avoid the vicious cyclic dependency.
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> -------------------------------------------------------------------------------
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
> Reporter: John Blum
> Priority: Blocker
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
