[PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Ju@N]

Hello all,

The current approach used to authorize methods during OQL execution seems
to be way too restrictive, I've drafted a proposal to change the current
behavior and allow further customization:
https://cwiki.apache.org/confluence/display/GEODE/Customizable+Security+When+Invoking+Methods+in+OQL


Please have a look and provide your feedback on the proposal.
Best regards.

-- 
Ju@N

Re: [PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Dave Barnes]

Juan,
Nice work - you've obviously given this plenty of thought. I'm not
qualified to comment on the technical aspects of your proposal, but as a
proofreader I noticed that there are a couple of occurrences of
"invokation" that should be spelled "invocation".
Dave



On Mon, Jun 25, 2018 at 2:52 AM, Ju@N  wrote:

> Hello all,
>
> The current approach used to authorize methods during OQL execution seems
> to be way too restrictive, I've drafted a proposal to change the current
> behavior and allow further customization:
> https://cwiki.apache.org/confluence/display/GEODE/
> Customizable+Security+When+Invoking+Methods+in+OQL
>
>
> Please have a look and provide your feedback on the proposal.
> Best regards.
>
> --
> Ju@N
>

Re: [PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Juan José Ramos]

Hello Dave,

Thanks for the heads up, spelling errors fixed (at least that one :-/).
Cheers!.


On Mon, Jun 25, 2018 at 4:34 PM Dave Barnes  wrote:

> Juan,
> Nice work - you've obviously given this plenty of thought. I'm not
> qualified to comment on the technical aspects of your proposal, but as a
> proofreader I noticed that there are a couple of occurrences of
> "invokation" that should be spelled "invocation".
> Dave
>
>
>
> On Mon, Jun 25, 2018 at 2:52 AM, Ju@N  wrote:
>
> > Hello all,
> >
> > The current approach used to authorize methods during OQL execution seems
> > to be way too restrictive, I've drafted a proposal to change the current
> > behavior and allow further customization:
> > https://cwiki.apache.org/confluence/display/GEODE/
> > Customizable+Security+When+Invoking+Methods+in+OQL
> >
> >
> > Please have a look and provide your feedback on the proposal.
> > Best regards.
> >
> > --
> > Ju@N
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Compilation errors in IntelliJ

[Dan Smith]

Intellij should now build geode just fine with the default gradle settings
as of 226e406.  If you followed these instructions to uncheck "Create
separate modules per source" to get things working last week you might want
to reimport the gradle project with the default settings.

-Dan


On Thu, Jun 21, 2018 at 2:40 PM, Kirk Lund  wrote:
>
> > After the recent Gradle upgrade, you might see some compilation errors in
> > IntelliJ involving geode-pulse such as the following:
> >
> > /Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/
> > apache/geode/tools/pulse/internal/service/MemberDetailsService.java
> > Error:(28, 46) java: package org.springframework.context.annotation does
> > not exist
> > Error:(29, 38) java: package org.springframework.stereotype does not
> exist
> > Error:(30, 38) java: package org.springframework.stereotype does not
> exist
> > Error:(42, 2) java: cannot find symbol
> >   symbol: class Component
> > Error:(43, 2) java: cannot find symbol
> >   symbol: class Service
> > Error:(44, 2) java: cannot find symbol
> >   symbol: class Scope
> >
> > To resolve this, open:
> >
> > Preferences -> Build, Execution, Deployment -> BuildTools -> Gradle
> >
> > There you’ll see your Geode project under the “Linked Gradle projects” —
> > you need to select it and then deselect “Create separate module per
> source
> > set.”
> >
> > This worked for me.
> >
> > Thanks,
> > Kirk
> >
>

Re: Compilation errors in IntelliJ

[Kirk Lund]

I've pulled, done a clean build, recreated my IntelliJ project and still
see this compilation error in buildSrc:

/Users/klund/dev/gemfire_CLEAN/open/buildSrc/src/test/
java/org/apache/geode/javac/TestCompiler.java
Error:(40, 23) java: cannot find symbol
  symbol:   class EnsureCorrectRunsWithProcessor
  location: class org.apache.geode.javac.TestCompiler

Any idea how to resolve this? (projects with a revision prior to the Gradle
upgrade don't hit this error)

On Mon, Jun 25, 2018 at 11:55 AM, Dan Smith  wrote:

> Intellij should now build geode just fine with the default gradle settings
> as of 226e406.  If you followed these instructions to uncheck "Create
> separate modules per source" to get things working last week you might want
> to reimport the gradle project with the default settings.
>
> -Dan
>
>
> On Thu, Jun 21, 2018 at 2:40 PM, Kirk Lund  wrote:
> >
> > > After the recent Gradle upgrade, you might see some compilation errors
> in
> > > IntelliJ involving geode-pulse such as the following:
> > >
> > > /Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/
> > > apache/geode/tools/pulse/internal/service/MemberDetailsService.java
> > > Error:(28, 46) java: package org.springframework.context.annotation
> does
> > > not exist
> > > Error:(29, 38) java: package org.springframework.stereotype does not
> > exist
> > > Error:(30, 38) java: package org.springframework.stereotype does not
> > exist
> > > Error:(42, 2) java: cannot find symbol
> > >   symbol: class Component
> > > Error:(43, 2) java: cannot find symbol
> > >   symbol: class Service
> > > Error:(44, 2) java: cannot find symbol
> > >   symbol: class Scope
> > >
> > > To resolve this, open:
> > >
> > > Preferences -> Build, Execution, Deployment -> BuildTools -> Gradle
> > >
> > > There you’ll see your Geode project under the “Linked Gradle projects”
> —
> > > you need to select it and then deselect “Create separate module per
> > source
> > > set.”
> > >
> > > This worked for me.
> > >
> > > Thanks,
> > > Kirk
> > >
> >
>

Re: Compilation errors in IntelliJ

[Kirk Lund]

I'm also seeing two problems on the command-line. 1) occasionally a build
(without tests) will hang in one the compile targets and 2) I just started
seeing occasional out of memory errors building with gradle (see below).

*> Task :geode-lucene:compileTestJava*



The system is out of resources.

Consult the following stack trace for details.

java.lang.OutOfMemoryError: Java heap space

at
com.sun.tools.javac.file.ZipFileIndex.readBytes(ZipFileIndex.java:380)

at com.sun.tools.javac.file.ZipFileIndex.read(ZipFileIndex.java:359)

at
com.sun.tools.javac.file.ZipFileIndexArchive$ZipFileIndexFileObject.openInputStream(ZipFileIndexArchive.java:151)

at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2510)

at
com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2442)

at
com.sun.tools.javac.jvm.ClassReader.access$000(ClassReader.java:76)

at
com.sun.tools.javac.jvm.ClassReader$1.complete(ClassReader.java:240)

at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)

at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037)

at
com.sun.tools.javac.jvm.ClassReader.loadClass(ClassReader.java:2623)

at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1907)

at
com.sun.tools.javac.comp.Resolve.findIdentInPackage(Resolve.java:2146)

at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3391)

at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3278)

at
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)

at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576)

at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638)

at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631)

at
com.sun.tools.javac.comp.MemberEnter.attribImportType(MemberEnter.java:834)

at
com.sun.tools.javac.comp.MemberEnter.visitImport(MemberEnter.java:558)

at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.java:571)

at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437)

at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:449)

at
com.sun.tools.javac.comp.MemberEnter.visitTopLevel(MemberEnter.java:528)

at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:518)

at
com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:437)

at
com.sun.tools.javac.comp.MemberEnter.complete(MemberEnter.java:1038)

at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)

at
com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1037)

at com.sun.tools.javac.comp.Enter.complete(Enter.java:493)

at com.sun.tools.javac.comp.Enter.main(Enter.java:471)

at
com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:982)


*> Task :geode-lucene:compileTestJava* FAILED

*<**===**--> 84% EXECUTING [2h 23m 18s]*


On Mon, Jun 25, 2018 at 1:11 PM, Kirk Lund  wrote:

> I've pulled, done a clean build, recreated my IntelliJ project and still
> see this compilation error in buildSrc:
>
> /Users/klund/dev/gemfire_CLEAN/open/buildSrc/src/test/java/
> org/apache/geode/javac/TestCompiler.java
> Error:(40, 23) java: cannot find symbol
>   symbol:   class EnsureCorrectRunsWithProcessor
>   location: class org.apache.geode.javac.TestCompiler
>
> Any idea how to resolve this? (projects with a revision prior to the
> Gradle upgrade don't hit this error)
>
> On Mon, Jun 25, 2018 at 11:55 AM, Dan Smith  wrote:
>
>> Intellij should now build geode just fine with the default gradle settings
>> as of 226e406.  If you followed these instructions to uncheck "Create
>> separate modules per source" to get things working last week you might
>> want
>> to reimport the gradle project with the default settings.
>>
>> -Dan
>>
>>
>> On Thu, Jun 21, 2018 at 2:40 PM, Kirk Lund  wrote:
>> >
>> > > After the recent Gradle upgrade, you might see some compilation
>> errors in
>> > > IntelliJ involving geode-pulse such as the following:
>> > >
>> > > /Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/
>> > > apache/geode/tools/pulse/internal/service/MemberDetailsService.java
>> > > Error:(28, 46) java: package org.springframework.context.annotation
>> does
>> > > not exist
>> > > Error:(29, 38) java: package org.springframework.stereotype does not
>> > exist
>> > > Error:(30, 38) java: package org.springframework.stereotype does not
>> > exist
>> > > Error:(42, 2) java: cannot find symbol
>> > >   symbol: class Component
>> > > Error:(43, 2) java: cannot find symbol
>> > >   symbol: class Service
>> > > Error:(44, 2) java: cannot find symbol
>> > >   symbol: class Scope
>> > >
>> > > To resolve this, open:
>> > >
>> > > Preferences -> Build, Execution, Deployment -> BuildTools -> Gradle
>> > >
>> > > There you’ll see your Geode project under the “Linked Gradle
>> project

Geode unit tests completed in 'develop/AcceptanceTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/115

Geode unit tests completed in 'develop/UITests' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/116

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #959 was successful.
---
Scheduled
2425 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Compilation errors in IntelliJ

[Kirk Lund]

After upgrading from JDK 1.8.0_152 to 1.8.0_172, I think my command-line
builds are behaving better.

Next IntelliJ failure was
https://intellij-support.jetbrains.com/hc/en-us/community/posts/36162670-In-2018-1-1-version-Problem-with-Error-cannot-start-process-the-working-directory-idea-modules-does-not-exist-
which didn't clear up until I upgraded from 2018.1 to 2018.1.5.

IntelliJ 2018.1.5 plus JDK 1.8.0_172 seems to work together on latest
develop.


On Mon, Jun 25, 2018 at 2:02 PM, Kirk Lund  wrote:

> I'm also seeing two problems on the command-line. 1) occasionally a build
> (without tests) will hang in one the compile targets and 2) I just started
> seeing occasional out of memory errors building with gradle (see below).
>
> *> Task :geode-lucene:compileTestJava*
>
>
>
> The system is out of resources.
>
> Consult the following stack trace for details.
>
> java.lang.OutOfMemoryError: Java heap space
>
> at com.sun.tools.javac.file.ZipFileIndex.readBytes(
> ZipFileIndex.java:380)
>
> at com.sun.tools.javac.file.ZipFileIndex.read(
> ZipFileIndex.java:359)
>
> at com.sun.tools.javac.file.ZipFileIndexArchive$
> ZipFileIndexFileObject.openInputStream(ZipFileIndexArchive.java:151)
>
> at com.sun.tools.javac.jvm.ClassReader.fillIn(
> ClassReader.java:2510)
>
> at com.sun.tools.javac.jvm.ClassReader.complete(
> ClassReader.java:2442)
>
> at com.sun.tools.javac.jvm.ClassReader.access$000(
> ClassReader.java:76)
>
> at com.sun.tools.javac.jvm.ClassReader$1.complete(
> ClassReader.java:240)
>
> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)
>
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(
> Symbol.java:1037)
>
> at com.sun.tools.javac.jvm.ClassReader.loadClass(
> ClassReader.java:2623)
>
> at com.sun.tools.javac.comp.Resolve.loadClass(Resolve.java:1907)
>
> at com.sun.tools.javac.comp.Resolve.findIdentInPackage(
> Resolve.java:2146)
>
> at com.sun.tools.javac.comp.Attr.selectSym(Attr.java:3391)
>
> at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3278)
>
> at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(
> JCTree.java:1897)
>
> at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:576)
>
> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:638)
>
> at com.sun.tools.javac.comp.Attr.attribType(Attr.java:631)
>
> at com.sun.tools.javac.comp.MemberEnter.attribImportType(
> MemberEnter.java:834)
>
> at com.sun.tools.javac.comp.MemberEnter.visitImport(
> MemberEnter.java:558)
>
> at com.sun.tools.javac.tree.JCTree$JCImport.accept(JCTree.
> java:571)
>
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(
> MemberEnter.java:437)
>
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(
> MemberEnter.java:449)
>
> at com.sun.tools.javac.comp.MemberEnter.visitTopLevel(
> MemberEnter.java:528)
>
> at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.
> accept(JCTree.java:518)
>
> at com.sun.tools.javac.comp.MemberEnter.memberEnter(
> MemberEnter.java:437)
>
> at com.sun.tools.javac.comp.MemberEnter.complete(
> MemberEnter.java:1038)
>
> at com.sun.tools.javac.code.Symbol.complete(Symbol.java:574)
>
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(
> Symbol.java:1037)
>
> at com.sun.tools.javac.comp.Enter.complete(Enter.java:493)
>
> at com.sun.tools.javac.comp.Enter.main(Enter.java:471)
>
> at com.sun.tools.javac.main.JavaCompiler.enterTrees(
> JavaCompiler.java:982)
>
>
> *> Task :geode-lucene:compileTestJava* FAILED
>
> *<**===**--> 84% EXECUTING [2h 23m 18s]*
>
>
> On Mon, Jun 25, 2018 at 1:11 PM, Kirk Lund  wrote:
>
>> I've pulled, done a clean build, recreated my IntelliJ project and still
>> see this compilation error in buildSrc:
>>
>> /Users/klund/dev/gemfire_CLEAN/open/buildSrc/src/test/java/o
>> rg/apache/geode/javac/TestCompiler.java
>> Error:(40, 23) java: cannot find symbol
>>   symbol:   class EnsureCorrectRunsWithProcessor
>>   location: class org.apache.geode.javac.TestCompiler
>>
>> Any idea how to resolve this? (projects with a revision prior to the
>> Gradle upgrade don't hit this error)
>>
>> On Mon, Jun 25, 2018 at 11:55 AM, Dan Smith  wrote:
>>
>>> Intellij should now build geode just fine with the default gradle
>>> settings
>>> as of 226e406.  If you followed these instructions to uncheck "Create
>>> separate modules per source" to get things working last week you might
>>> want
>>> to reimport the gradle project with the default settings.
>>>
>>> -Dan
>>>
>>>
>>> On Thu, Jun 21, 2018 at 2:40 PM, Kirk Lund  wrote:
>>> >
>>> > > After the recent Gradle upgrade, you might see some compilation
>>> errors in
>>> > > IntelliJ involving geode-pulse such as the following:
>>> > >
>>> > > /Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/
>>> > > apache/geode/tools/pulse/internal/

Build failed in Jenkins: Geode-nightly #1236

[Apache Jenkins Server]

See 


Changes:

[github] GEODE-4791: Fix intellij with gradle 4.8 by removing provided

[github] Write a test that hangs without the fix for GEODE-3563. (#2057)

[github] GEODE-4511: rework ClientAuthDUnitRule to illustrate when authenticat…

--
[...truncated 42.85 KB...]
> Task :geode-connectors:spotlessJava UP-TO-DATE
> Task :geode-connectors:spotlessJavaCheck UP-TO-DATE
> Task :geode-connectors:spotlessCheck UP-TO-DATE
> Task :geode-connectors:test
> Task :geode-core:assemble
> Task :geode-core:checkMissedTests
> Task :geode-core:spotlessJava
> Task :geode-core:spotlessJavaCheck
> Task :geode-core:spotlessCheck
> Task :geode-core:test
> Task :geode-cq:assemble

> Task :geode-cq:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-cq:processTestResources
> Task :geode-cq:testClasses
> Task :geode-cq:checkMissedTests
> Task :geode-cq:spotlessJava UP-TO-DATE
> Task :geode-cq:spotlessJavaCheck UP-TO-DATE
> Task :geode-cq:spotlessCheck UP-TO-DATE
> Task :geode-cq:test
> Task :geode-experimental-driver:jar
> Task :geode-experimental-driver:javadoc FROM-CACHE
> Task :geode-experimental-driver:javadocJar
> Task :geode-experimental-driver:sourcesJar
> Task :geode-experimental-driver:signArchives SKIPPED
> Task :geode-experimental-driver:assemble

> Task :geode-experimental-driver:compileTestJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-experimental-driver:processTestResources
> Task :geode-experimental-driver:testClasses
> Task :geode-experimental-driver:checkMissedTests
> Task :geode-experimental-driver:spotlessJava UP-TO-DATE
> Task :geode-experimental-driver:spotlessJavaCheck UP-TO-DATE
> Task :geode-experimental-driver:spotlessCheck UP-TO-DATE
> Task :geode-experimental-driver:test
> Task :geode-json:assemble
> Task :geode-json:compileTestJava NO-SOURCE
> Task :geode-json:processTestResources
> Task :geode-json:testClasses
> Task :geode-json:checkMissedTests NO-SOURCE
> Task :geode-json:spotlessJava UP-TO-DATE
> Task :geode-json:spotlessJavaCheck UP-TO-DATE
> Task :geode-json:spotlessCheck UP-TO-DATE
> Task :geode-json:test NO-SOURCE
> Task :geode-old-versions:javadoc NO-SOURCE
> Task :geode-junit:javadoc
> Task :geode-junit:javadocJar
> Task :geode-junit:sourcesJar
> Task :geode-junit:signArchives SKIPPED
> Task :geode-junit:assemble

> Task :geode-junit:compileTestJava
Note: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-junit:processTestResources
> Task :geode-junit:testClasses
> Task :geode-junit:checkMissedTests
> Task :geode-junit:spotlessJava
> Task :geode-junit:spotlessJavaCheck
> Task :geode-junit:spotlessCheck
> Task :geode-junit:test
> Task :geode-lucene:assemble

> Task :geode-lucene:compileTestJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-lucene:processTestResources
> Task :geode-lucene:testClasses
> Task :geode-lucene:checkMissedTests
> Task :geode-lucene:spotlessJava UP-TO-DATE
> Task :geode-lucene:spotlessJavaCheck UP-TO-DATE
> Task :geode-lucene:spotlessCheck UP-TO-DATE
> Task :geode-lucene:test
> Task :geode-old-client-support:assemble
> Task :geode-old-client-support:compileTestJava
> Task :geode-old-client-support:processTestResources NO-SOURCE
> Task :geode-old-client-support:testClasses
> Task :geode-old-client-support:checkMissedTests
> Task :geode-old-client-support:spotlessJava UP-TO-DATE
> Task :geode-old-client-support:spotlessJavaCheck UP-TO-DATE
> Task :geode-old-client-support:spotlessCheck UP-TO-DATE
> Task :geode-old-client-support:test
> Task :geode-old-versions:javadocJar
> Task :geode-old-versions:sourcesJar
> Task :geode-old-versions:signArchives SKIPPED
> Task :geode-old-versions:assemble
> Task :geode-old-versions:compileTestJava NO-SOURCE
> Task :geode-old-versions:processTestResources NO-SOURCE
> Task :geode-old-versions:testClasses UP-TO-DATE
> Task :geode-old-versions:checkMissedTests NO-SOURCE
> Task :geode-old-versions:spotlessJava
> Task :geode-old-versions:spotlessJavaCheck
> Task :geode-old-versions:spotlessCheck
> Task :geode-old-versions:test NO-SOURCE
> Task :geode-p

Spring Boot for Apache Geode 1.0.0.M1 Released!

[John Blum]

Apache Geode Community-

It is my please to announce the first milestone release of Spring Boot for
Apache Geode, version 1.0.0.M1.

See the official Spring Blog Post [1] for more details.

Documentation [2] is available as are a couple of Examples [3].

Feedback appreciated and welcomed.

Much more to follow soon; stay tuned!

Regards,

-- 
-John

[1]
https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released
[2]
https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released#documentation
[3]
https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released#examples

Geode unit tests 'develop/DistributedTest' took too long to execute

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/79