Re: Review Request 60125: GEODE-3062: replace SecurityService after loading cluster config [FIXED]

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60125/#review178082
---




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
Lines 822 (patched)


after you rebase to develop, this line will become:

this.securityService = 
SecurityServiceFactory.create(system.getSecurityProperties(), cacheConfig);


- Jinmei Liao


On June 15, 2017, 11:44 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60125/
> ---
> 
> (Updated June 15, 2017, 11:44 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-3062
> https://issues.apache.org/jira/browse/GEODE-3062
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Fixes:
> a) moved deployment of cluster config jars back to initalize after 
> ClassPathLoader
> b) added DistributedSystem#disconnect to ServerStarterRule "after" (tests 
> which fail during Cache create have no GemFireCacheImpl singleton but they do 
> have a InternalDistributedSystem singleton)
> 
> Add new test to ClusterConfigWithSecurityDUnitTest that fails due to bug 
> GEODE-3062.
> 
> Remove unused Cache param from applyClusterPropertiesConfiguration so it can 
> be called during Cache construction.
> 
> Move cluster config request to Cache construction and handle jars and 
> properties there. Create new SecurityService in constructor and overwrite the 
> SecurityService in InternalDistributedSystem.
> 
> NOTE: We will later have to fix GEODE-3061 by moving cluster config request 
> from Cache to InternalDistributedSystem construction so that IDS can be 
> created with gemfire.properties from cluster config. At that time we would 
> rip out both cluster config request and creation of security service from 
> Cache construction and pass both into Cache construction.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  22edb6f06c7791929cc9a033ca1a1bfed5751a47 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  4f4881fe39116faa505bc2fbec74efd669efe0ef 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
>  c551ca9104a85dcf54c0bebbc4178fce4114a416 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  fa3e8c0f0bb2fdbf55724e1ba78de7babb5f01b8 
> 
> 
> Diff: https://reviews.apache.org/r/60125/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 60142: GEODE-3071: Provide capability to parallelize distributedTests

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60142/#review178075
---



Thank you Jens!  This is awesome.

- Jared Stewart


On June 16, 2017, 12:59 a.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60142/
> ---
> 
> (Updated June 16, 2017, 12:59 a.m.)
> 
> 
> Review request for geode, Anthony Baker, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Herewith the ability to leverage Gradle's parallel test execution
> capability to run dunits in parallel. This is combined with launching
> tests in Docker containers to provide process, network and filesystem
> isolation. Depending on the size of your system, this can speed up
> running the distributedTest task 2-5 times.
> 
> The capability is enabled by launching gradle with '-PparallelDunit'
> 
> Tunables, enabled as gradle parametrs (-P option) are:
> 
> - dunitDockerImage: The docker image which will be used to launch
>   tests. The image must have the JAVA_HOME environment variable set. The
>   image must be pulled locally before starting the tests.
> - dunitParallelForks: The number of parallel docker containers to be
>   launched.
> - dunitDockerUser: The docker user which will run the tests. Because of
>   the way that the containers map the build directory into them, the
>   test artifacts, will be written with this user id. By default this is
>   'root'.
> 
> Remove debug println
> 
> NOTE: There are problems running this on MacOS which will require a bit more 
> work.
> 
> 
> Diffs
> -
> 
>   build.gradle ec6b920c825491030120e99d288067d476d1fdcb 
>   gradle.properties ca79a3816bffa56e412d82dd570f1e0e445592be 
>   gradle/docker.gradle PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60142/diff/1/
> 
> 
> Testing
> ---
> 
> Manual test on linux
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 60142: GEODE-3071: Provide capability to parallelize distributedTests

[Anthony Baker]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60142/#review178070
---



So much awesome.

- Anthony Baker


On June 16, 2017, 12:59 a.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60142/
> ---
> 
> (Updated June 16, 2017, 12:59 a.m.)
> 
> 
> Review request for geode, Anthony Baker, Mark Bretl, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Herewith the ability to leverage Gradle's parallel test execution
> capability to run dunits in parallel. This is combined with launching
> tests in Docker containers to provide process, network and filesystem
> isolation. Depending on the size of your system, this can speed up
> running the distributedTest task 2-5 times.
> 
> The capability is enabled by launching gradle with '-PparallelDunit'
> 
> Tunables, enabled as gradle parametrs (-P option) are:
> 
> - dunitDockerImage: The docker image which will be used to launch
>   tests. The image must have the JAVA_HOME environment variable set. The
>   image must be pulled locally before starting the tests.
> - dunitParallelForks: The number of parallel docker containers to be
>   launched.
> - dunitDockerUser: The docker user which will run the tests. Because of
>   the way that the containers map the build directory into them, the
>   test artifacts, will be written with this user id. By default this is
>   'root'.
> 
> Remove debug println
> 
> NOTE: There are problems running this on MacOS which will require a bit more 
> work.
> 
> 
> Diffs
> -
> 
>   build.gradle ec6b920c825491030120e99d288067d476d1fdcb 
>   gradle.properties ca79a3816bffa56e412d82dd570f1e0e445592be 
>   gradle/docker.gradle PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/60142/diff/1/
> 
> 
> Testing
> ---
> 
> Manual test on linux
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Review Request 60142: GEODE-3071: Provide capability to parallelize distributedTests

[Jens Deppe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60142/
---

Review request for geode, Anthony Baker, Mark Bretl, and Dan Smith.


Repository: geode


Description
---

Herewith the ability to leverage Gradle's parallel test execution
capability to run dunits in parallel. This is combined with launching
tests in Docker containers to provide process, network and filesystem
isolation. Depending on the size of your system, this can speed up
running the distributedTest task 2-5 times.

The capability is enabled by launching gradle with '-PparallelDunit'

Tunables, enabled as gradle parametrs (-P option) are:

- dunitDockerImage: The docker image which will be used to launch
  tests. The image must have the JAVA_HOME environment variable set. The
  image must be pulled locally before starting the tests.
- dunitParallelForks: The number of parallel docker containers to be
  launched.
- dunitDockerUser: The docker user which will run the tests. Because of
  the way that the containers map the build directory into them, the
  test artifacts, will be written with this user id. By default this is
  'root'.

Remove debug println

NOTE: There are problems running this on MacOS which will require a bit more 
work.


Diffs
-

  build.gradle ec6b920c825491030120e99d288067d476d1fdcb 
  gradle.properties ca79a3816bffa56e412d82dd570f1e0e445592be 
  gradle/docker.gradle PRE-CREATION 


Diff: https://reviews.apache.org/r/60142/diff/1/


Testing
---

Manual test on linux


Thanks,

Jens Deppe

[GitHub] geode issue #584: GEODE-2901: Adding integration tests of session replicatio...

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/584
  
@ladyVader @nabarunnag @boglesby @jhuynh1 @upthewaterspout @gesterzhou


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #584: GEODE-2901: Adding integration tests of session rep...

[DivineEnder]

GitHub user DivineEnder opened a pull request:

https://github.com/apache/geode/pull/584

GEODE-2901: Adding integration tests of session replication

Adding integration tests that test both session replications
frameworks shipped with geode. These tests use cargo to download
and launch different J2EE containers, so the tests can run
against many different containers.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/DivineEnder/geode feature/GEODE-2901

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/584.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #584


commit 75943c5e6a1d1c9d4f23ca423f1766a0a854a5dc
Author: David Anuta 
Date:   2017-05-27T00:07:36Z

GEODE-2901: Adding integration tests of session replication

Adding integration tests that test both session replications
frameworks shipped with geode. These tests use cargo to download
and launch different J2EE containers, so the tests can run
against many different containers.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 60125: GEODE-3062: replace SecurityService after loading cluster config [FIXED]

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60125/#review178065
---




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
Lines 945 (patched)


this is just a one-line method, maybe just get rid of it, and have the 
caller directly call requestSharedConfiguration()?



geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
Line 1158 (original), 1173 (patched)


since this.configurationResponse is a member variable now, we don't need to 
pass it to this method as well.



geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
Lines 132 (patched)


I am surprised that server.stop() does not call this ds.stop().

would this also apply to LocatorStarterRule as well? If so, we should add 
this block to the parent's class(MemberStarterRule)'s stop() method.


- Jinmei Liao


On June 15, 2017, 11:44 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60125/
> ---
> 
> (Updated June 15, 2017, 11:44 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-3062
> https://issues.apache.org/jira/browse/GEODE-3062
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Fixes:
> a) moved deployment of cluster config jars back to initalize after 
> ClassPathLoader
> b) added DistributedSystem#disconnect to ServerStarterRule "after" (tests 
> which fail during Cache create have no GemFireCacheImpl singleton but they do 
> have a InternalDistributedSystem singleton)
> 
> Add new test to ClusterConfigWithSecurityDUnitTest that fails due to bug 
> GEODE-3062.
> 
> Remove unused Cache param from applyClusterPropertiesConfiguration so it can 
> be called during Cache construction.
> 
> Move cluster config request to Cache construction and handle jars and 
> properties there. Create new SecurityService in constructor and overwrite the 
> SecurityService in InternalDistributedSystem.
> 
> NOTE: We will later have to fix GEODE-3061 by moving cluster config request 
> from Cache to InternalDistributedSystem construction so that IDS can be 
> created with gemfire.properties from cluster config. At that time we would 
> rip out both cluster config request and creation of security service from 
> Cache construction and pass both into Cache construction.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  22edb6f06c7791929cc9a033ca1a1bfed5751a47 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  4f4881fe39116faa505bc2fbec74efd669efe0ef 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
>  c551ca9104a85dcf54c0bebbc4178fce4114a416 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  fa3e8c0f0bb2fdbf55724e1ba78de7babb5f01b8 
> 
> 
> Diff: https://reviews.apache.org/r/60125/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

[GitHub] geode pull request #582: GEODE-2601: Fix banner being logged twice

[pdxrunner]

Github user pdxrunner commented on a diff in the pull request:

https://github.com/apache/geode/pull/582#discussion_r122332971
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
 ---
@@ -469,15 +470,13 @@ private InternalLocator(int port, File logF, File 
stateF, InternalLogWriter logW
 
LogWriterAppenders.getOrCreateAppender(LogWriterAppenders.Identifier.SECURITY, 
true, false,
 this.config, false);
 
--- End diff --

delete extra blank line


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #582: GEODE-2601: Fix banner being logged twice

[pdxrunner]

Github user pdxrunner commented on a diff in the pull request:

https://github.com/apache/geode/pull/582#discussion_r122332566
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 ---
@@ -2167,7 +2191,7 @@ private static void 
notifyReconnectListeners(InternalDistributedSystem oldsys,
   private void notifyResourceEventListeners(ResourceEvent event, Object 
resource) {
 for (Iterator iter = 
resourceListeners.iterator(); iter.hasNext();) {
--- End diff --

This loop looks like it could be rewritten  as a foreach type loop

`
for (ResourceEventListnener listener:resourceListeners) {
  ...
}
`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #586 was SUCCESSFUL (with 1868 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #586 was successful.
---
Scheduled
1870 tests in total.

https://build.spring.io/browse/SGF-NAG-586/





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode pull request #583: GEODE-2854: GEODE REST API Docs Missing Authenticat...

[karensmolermiller]

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/583#discussion_r122326144
  
--- Diff: geode-docs/rest_apps/setup_config.html.md.erb ---
@@ -29,162 +31,233 @@ All Geode REST interface classes and required JAR 
files are distributed as a WAR
 
 where _install-dir_ is the server installation directory and _n.n.n_ is a 
version number.
 
-To enable the developer REST API service in Apache Geode, set the 
`start-dev-rest-api` Geode property to `true` when starting a data node using 
either `gfsh` or the ServerLauncher API. Setting this property to true on a 
data node will start up an embedded Jetty server and deploy the REST developer 
API WAR file.
+- [Enabling the REST API](#setup_config_enabling_rest)
+- [Starting the REST API Service](#setup_config_starting_rest)
+- [Implementing Authentication for the REST 
API](#setup_config_implementing_auth)
+- [Programmatic Startup](#setup_config_implementing_auth)
+
+# Enabling 
the REST API
+
+The REST API service for application development runs only on data nodes; 
you cannot run the service on a locator.
+
+To enable the Developer REST API service on a given server, set the 
`start-dev-rest-api` property
+to `true` when starting the data node to start an embedded Jetty server 
and deploy the Developer REST
+API WAR file on that node. Use either the `gfsh start server` command or 
the ServerLauncher API to enable this property.
--- End diff --

To help me parse what is getting started and where with the property, can 
you add a comma or reword the sentence?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Review Request 60125: GEODE-3062: replace SecurityService after loading cluster config [FIXED]

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60125/
---

Review request for geode, Emily Yeh, Jinmei Liao, Ken Howe, and Patrick 
Rhomberg.


Bugs: GEODE-3062
https://issues.apache.org/jira/browse/GEODE-3062


Repository: geode


Description
---

Fixes:
a) moved deployment of cluster config jars back to initalize after 
ClassPathLoader
b) added DistributedSystem#disconnect to ServerStarterRule "after" (tests which 
fail during Cache create have no GemFireCacheImpl singleton but they do have a 
InternalDistributedSystem singleton)

Add new test to ClusterConfigWithSecurityDUnitTest that fails due to bug 
GEODE-3062.

Remove unused Cache param from applyClusterPropertiesConfiguration so it can be 
called during Cache construction.

Move cluster config request to Cache construction and handle jars and 
properties there. Create new SecurityService in constructor and overwrite the 
SecurityService in InternalDistributedSystem.

NOTE: We will later have to fix GEODE-3061 by moving cluster config request 
from Cache to InternalDistributedSystem construction so that IDS can be created 
with gemfire.properties from cluster config. At that time we would rip out both 
cluster config request and creation of security service from Cache construction 
and pass both into Cache construction.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 22edb6f06c7791929cc9a033ca1a1bfed5751a47 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 4f4881fe39116faa505bc2fbec74efd669efe0ef 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
 c551ca9104a85dcf54c0bebbc4178fce4114a416 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 fa3e8c0f0bb2fdbf55724e1ba78de7babb5f01b8 


Diff: https://reviews.apache.org/r/60125/diff/1/


Testing
---

precheckin in progress


Thanks,

Kirk Lund

[GitHub] geode pull request #583: GEODE-2854: GEODE REST API Docs Missing Authenticat...

[joeymcallister]

Github user joeymcallister commented on a diff in the pull request:

https://github.com/apache/geode/pull/583#discussion_r122319962
  
--- Diff: geode-docs/rest_apps/setup_config.html.md.erb ---
@@ -29,162 +31,233 @@ All Geode REST interface classes and required JAR 
files are distributed as a WAR
 
 where _install-dir_ is the server installation directory and _n.n.n_ is a 
version number.
 
-To enable the developer REST API service in Apache Geode, set the 
`start-dev-rest-api` Geode property to `true` when starting a data node using 
either `gfsh` or the ServerLauncher API. Setting this property to true on a 
data node will start up an embedded Jetty server and deploy the REST developer 
API WAR file.
+- [Enabling the REST API](#setup_config_enabling_rest)
+- [Starting the REST API Service](#setup_config_starting_rest)
+- [Implementing Authentication for the REST 
API](#setup_config_implementing_auth)
+- [Programmatic Startup](#setup_config_implementing_auth)
+
+# Enabling 
the REST API
+
+The REST API service for application development runs only on data nodes; 
you cannot run the service on a locator.
+
+To enable the Developer REST API service on a given server, set the 
`start-dev-rest-api` property
+to `true` when starting the data node to start an embedded Jetty server 
and deploy the Developer REST
+API WAR file on that node. Use either the `gfsh start server` command or 
the ServerLauncher API to enable this property.
 
-**Note:**
-The REST API service for application development runs only on servers; you 
cannot use locators to host the developer Geode REST API services.
+## Enabling the REST API on Multiple Nodes
 
-You can have multiple REST enabled data nodes in a single distributed 
system. Each data node should
+You can configure multiple REST enabled data nodes in a single distributed 
system. Each data node should
 have a separate host name and unique end point. To ensure that the data 
node is reachable on a
-machine with multiple NIC addresses, you can use 
`http-service-bind-address` to bind an address to
-the REST API service (as well as the other embedded web services such as 
Pulse).
+machine with multiple NIC addresses, use `http-service-bind-address` to 
bind an address to
+the REST API service (as well as the other embedded web services, such as 
Pulse).
 
-You can also configure the Developer REST API service to run over
-HTTPS by enabling ssl for the `http` component in `gemfire.properties`
-or `gfsecurity.properties` or on server startup:
-See [SSL](../managing/security/ssl_overview.html) for details on 
configuring SSL parameters.
-These SSL parameters apply to all HTTP services hosted on the configured 
server, which can include the following:
+You can configure the Developer REST API service to run over HTTPS by 
enabling SSL for the `http`
+component in `gemfire.properties` or `gfsecurity.properties`, or on server 
startup.  See
+[SSL](../managing/security/ssl_overview.html) for details on configuring 
SSL parameters.  These SSL
+parameters apply to all HTTP services hosted on the configured server, 
which can include the
+following:
 
 -   Developer REST API service
 -   Management REST API service (for remote cluster management)
 -   Pulse monitoring tool
 
-The following procedure starts up a REST API service-enabled Geode 
deployment:
+#  Starting 
the REST API Service
 
-1.  Configure PDX for your cluster. You must configure PDX if either or 
both of the following conditions apply: 
--   Application peer member caches will access REST-accessible Regions 
(resources) with the `Region.get(key)`.
--   Your deployment has persistent regions that must be available as 
resources to the REST API.  To configure PDX in your cluster, perform the 
following steps:
-1.  Start up a locator running the [cluster configuration 
service](../configuring/cluster_config/gfsh_persist.html) (enabled by default). 
For example: 
+To start a REST API service-enabled Geode deployment, configure PDX 
serialization for your
+cluster, then start the service on one or more server nodes.
 
-``` pre
-gfsh>start locator --name=locator1
-```
-2.  If your deployment has application peer member caches (for 
example, Java clients) that must also access REST-accessible Regions 
(resources), use the following gfsh command:
+## Configure PDX for your cluster
 
-``` pre
-gfsh>configure pdx --read-serialized=true
-```
-**Note:**
-You do not need to configure `--read-serialized=true` if no 
application peer member caches are accessing the REST-accessible regions 
(resources) in your deployment.
-3.  If your deployment 

[GitHub] geode pull request #583: GEODE-2854: GEODE REST API Docs Missing Authenticat...

[joeymcallister]

Github user joeymcallister commented on a diff in the pull request:

https://github.com/apache/geode/pull/583#discussion_r122320206
  
--- Diff: geode-docs/rest_apps/setup_config.html.md.erb ---
@@ -29,162 +31,233 @@ All Geode REST interface classes and required JAR 
files are distributed as a WAR
 
 where _install-dir_ is the server installation directory and _n.n.n_ is a 
version number.
 
-To enable the developer REST API service in Apache Geode, set the 
`start-dev-rest-api` Geode property to `true` when starting a data node using 
either `gfsh` or the ServerLauncher API. Setting this property to true on a 
data node will start up an embedded Jetty server and deploy the REST developer 
API WAR file.
+- [Enabling the REST API](#setup_config_enabling_rest)
+- [Starting the REST API Service](#setup_config_starting_rest)
+- [Implementing Authentication for the REST 
API](#setup_config_implementing_auth)
+- [Programmatic Startup](#setup_config_implementing_auth)
+
+# Enabling 
the REST API
+
+The REST API service for application development runs only on data nodes; 
you cannot run the service on a locator.
+
+To enable the Developer REST API service on a given server, set the 
`start-dev-rest-api` property
+to `true` when starting the data node to start an embedded Jetty server 
and deploy the Developer REST
+API WAR file on that node. Use either the `gfsh start server` command or 
the ServerLauncher API to enable this property.
 
-**Note:**
-The REST API service for application development runs only on servers; you 
cannot use locators to host the developer Geode REST API services.
+## Enabling the REST API on Multiple Nodes
 
-You can have multiple REST enabled data nodes in a single distributed 
system. Each data node should
+You can configure multiple REST enabled data nodes in a single distributed 
system. Each data node should
 have a separate host name and unique end point. To ensure that the data 
node is reachable on a
-machine with multiple NIC addresses, you can use 
`http-service-bind-address` to bind an address to
-the REST API service (as well as the other embedded web services such as 
Pulse).
+machine with multiple NIC addresses, use `http-service-bind-address` to 
bind an address to
+the REST API service (as well as the other embedded web services, such as 
Pulse).
 
-You can also configure the Developer REST API service to run over
-HTTPS by enabling ssl for the `http` component in `gemfire.properties`
-or `gfsecurity.properties` or on server startup:
-See [SSL](../managing/security/ssl_overview.html) for details on 
configuring SSL parameters.
-These SSL parameters apply to all HTTP services hosted on the configured 
server, which can include the following:
+You can configure the Developer REST API service to run over HTTPS by 
enabling SSL for the `http`
+component in `gemfire.properties` or `gfsecurity.properties`, or on server 
startup.  See
+[SSL](../managing/security/ssl_overview.html) for details on configuring 
SSL parameters.  These SSL
+parameters apply to all HTTP services hosted on the configured server, 
which can include the
+following:
 
 -   Developer REST API service
 -   Management REST API service (for remote cluster management)
 -   Pulse monitoring tool
 
-The following procedure starts up a REST API service-enabled Geode 
deployment:
+#  Starting 
the REST API Service
 
-1.  Configure PDX for your cluster. You must configure PDX if either or 
both of the following conditions apply: 
--   Application peer member caches will access REST-accessible Regions 
(resources) with the `Region.get(key)`.
--   Your deployment has persistent regions that must be available as 
resources to the REST API.  To configure PDX in your cluster, perform the 
following steps:
-1.  Start up a locator running the [cluster configuration 
service](../configuring/cluster_config/gfsh_persist.html) (enabled by default). 
For example: 
+To start a REST API service-enabled Geode deployment, configure PDX 
serialization for your
+cluster, then start the service on one or more server nodes.
 
-``` pre
-gfsh>start locator --name=locator1
-```
-2.  If your deployment has application peer member caches (for 
example, Java clients) that must also access REST-accessible Regions 
(resources), use the following gfsh command:
+## Configure PDX for your cluster
 
-``` pre
-gfsh>configure pdx --read-serialized=true
-```
-**Note:**
-You do not need to configure `--read-serialized=true` if no 
application peer member caches are accessing the REST-accessible regions 
(resources) in your deployment.
-3.  If your deployment 

[GitHub] geode pull request #583: GEODE-2854: GEODE REST API Docs Missing Authenticat...

[joeymcallister]

Github user joeymcallister commented on a diff in the pull request:

https://github.com/apache/geode/pull/583#discussion_r122320074
  
--- Diff: geode-docs/rest_apps/setup_config.html.md.erb ---
@@ -29,162 +31,233 @@ All Geode REST interface classes and required JAR 
files are distributed as a WAR
 
 where _install-dir_ is the server installation directory and _n.n.n_ is a 
version number.
 
-To enable the developer REST API service in Apache Geode, set the 
`start-dev-rest-api` Geode property to `true` when starting a data node using 
either `gfsh` or the ServerLauncher API. Setting this property to true on a 
data node will start up an embedded Jetty server and deploy the REST developer 
API WAR file.
+- [Enabling the REST API](#setup_config_enabling_rest)
+- [Starting the REST API Service](#setup_config_starting_rest)
+- [Implementing Authentication for the REST 
API](#setup_config_implementing_auth)
+- [Programmatic Startup](#setup_config_implementing_auth)
+
+# Enabling 
the REST API
+
+The REST API service for application development runs only on data nodes; 
you cannot run the service on a locator.
+
+To enable the Developer REST API service on a given server, set the 
`start-dev-rest-api` property
+to `true` when starting the data node to start an embedded Jetty server 
and deploy the Developer REST
+API WAR file on that node. Use either the `gfsh start server` command or 
the ServerLauncher API to enable this property.
 
-**Note:**
-The REST API service for application development runs only on servers; you 
cannot use locators to host the developer Geode REST API services.
+## Enabling the REST API on Multiple Nodes
 
-You can have multiple REST enabled data nodes in a single distributed 
system. Each data node should
+You can configure multiple REST enabled data nodes in a single distributed 
system. Each data node should
 have a separate host name and unique end point. To ensure that the data 
node is reachable on a
-machine with multiple NIC addresses, you can use 
`http-service-bind-address` to bind an address to
-the REST API service (as well as the other embedded web services such as 
Pulse).
+machine with multiple NIC addresses, use `http-service-bind-address` to 
bind an address to
+the REST API service (as well as the other embedded web services, such as 
Pulse).
 
-You can also configure the Developer REST API service to run over
-HTTPS by enabling ssl for the `http` component in `gemfire.properties`
-or `gfsecurity.properties` or on server startup:
-See [SSL](../managing/security/ssl_overview.html) for details on 
configuring SSL parameters.
-These SSL parameters apply to all HTTP services hosted on the configured 
server, which can include the following:
+You can configure the Developer REST API service to run over HTTPS by 
enabling SSL for the `http`
+component in `gemfire.properties` or `gfsecurity.properties`, or on server 
startup.  See
+[SSL](../managing/security/ssl_overview.html) for details on configuring 
SSL parameters.  These SSL
+parameters apply to all HTTP services hosted on the configured server, 
which can include the
+following:
 
 -   Developer REST API service
 -   Management REST API service (for remote cluster management)
 -   Pulse monitoring tool
 
-The following procedure starts up a REST API service-enabled Geode 
deployment:
+#  Starting 
the REST API Service
 
-1.  Configure PDX for your cluster. You must configure PDX if either or 
both of the following conditions apply: 
--   Application peer member caches will access REST-accessible Regions 
(resources) with the `Region.get(key)`.
--   Your deployment has persistent regions that must be available as 
resources to the REST API.  To configure PDX in your cluster, perform the 
following steps:
-1.  Start up a locator running the [cluster configuration 
service](../configuring/cluster_config/gfsh_persist.html) (enabled by default). 
For example: 
+To start a REST API service-enabled Geode deployment, configure PDX 
serialization for your
+cluster, then start the service on one or more server nodes.
 
-``` pre
-gfsh>start locator --name=locator1
-```
-2.  If your deployment has application peer member caches (for 
example, Java clients) that must also access REST-accessible Regions 
(resources), use the following gfsh command:
+## Configure PDX for your cluster
 
-``` pre
-gfsh>configure pdx --read-serialized=true
-```
-**Note:**
-You do not need to configure `--read-serialized=true` if no 
application peer member caches are accessing the REST-accessible regions 
(resources) in your deployment.
-3.  If your deployment 

[GitHub] geode pull request #583: GEODE-2854: GEODE REST API Docs Missing Authenticat...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

https://github.com/apache/geode/pull/583

GEODE-2854: GEODE REST API Docs Missing Authentication

Reviews requested from: @mmartell, @jaredjstewart @karensmolermiller 
@joeymcallister 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2854

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/583.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #583


commit a77860db914498585fb4bd90f27f3cd488e9
Author: Dave Barnes 
Date:   2017-06-15T20:43:41Z

GEODE-2854: GEODE REST API Docs Missing Authentication




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #578: GEODE-1958: Removing/deprecating PasswordUtil

[YehEmily]

Github user YehEmily commented on a diff in the pull request:

https://github.com/apache/geode/pull/578#discussion_r122279107
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/cache/util/PasswordUtilJUnitTest.java 
---
@@ -1,42 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
- * agreements. See the NOTICE file distributed with this work for 
additional information regarding
- * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
- * "License"); you may not use this file except in compliance with the 
License. You may obtain a
- * copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software 
distributed under the License
- * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
- * or implied. See the License for the specific language governing 
permissions and limitations under
- * the License.
- */
-package org.apache.geode.cache.util;
-
-import static org.junit.Assert.*;
-
-import org.junit.Test;
-import org.junit.experimental.categories.Category;
-
-import org.apache.geode.internal.util.PasswordUtil;
-import org.apache.geode.test.junit.categories.SecurityTest;
-import org.apache.geode.test.junit.categories.UnitTest;
-
-@Category({UnitTest.class, SecurityTest.class})
-public class PasswordUtilJUnitTest {
-
-  @Test
-  public void testPasswordUtil() {
-String x = "password";
-String z = null;
-
-// System.out.println(x);
-String y = PasswordUtil.encrypt(x);
--- End diff --

Fixed - thank you!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #581: GEODE-2301 Doc note to deprecate Geode JTA trans mg...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/581

GEODE-2301 Doc note to deprecate Geode JTA trans mgr

Simple addition to the beginning of the documentation of the Geode JTA 
transaction manager that the Geode JTA transaction manager is deprecated for 
1.2.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-2301

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/581.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #581


commit 76bed09aa11d45a6baa0e8883cf20dda720bcc2b
Author: Karen Miller 
Date:   2017-06-15T17:39:44Z

GEODE-2301 Doc note to deprecate Geode JTA trans mgr




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jenkins build is back to normal : Geode-release-flaky #15

[Apache Jenkins Server]

See