Re: [ANNOUNCE] Spring Data Geode 2.0.0.RELEASE (Kay GA) Available...

2017-10-05 Thread Nilkanth Patel 
Great work John. Congratulations..!

Nilkanth.

On Fri, Oct 6, 2017 at 12:09 AM, Jagdish Mirani  wrote:

> Cool - great progress John.
> Jag
>
> On Thu, Oct 5, 2017 at 10:51 AM, Michael Stolz  wrote:
>
> > Wow! Great stuff John!
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Lead
> > Mobile: +1-631-835-4771
> >
> > On Thu, Oct 5, 2017 at 6:35 PM, John Blum  wrote:
> >
> > > Dear Geode Community-
> > >
> > > After almost 1 year of radio silence on all things related to *Spring
> > > Data Geode* for Apache Geode, it is my pleasure to inform you that
> > *Spring
> > > Data Geode* *2.0.0.RELEASE* (Kay GA) is now available! [1]
> > >
> > > Many things have happened since my last announcement.
> > >
> > > First, *Spring Data Geode* 2.0 joins the *Spring Data Release Train*
> [2]
> > > as another top-level *Spring Data* module in the *Spring Data*
> portfolio.
> > > [3]  This is significant for few reasons, but most importantly, you can
> > > expect a predictable and regular series of SDG releases going forward,
> > and
> > > announcement from me when they occur.
> > >
> > > Next, *Spring Data Geode* 2.0 encompasses some key updates...
> > >
> > > * Upgrades to *Apache Geode 1.2.1*.
> > >
> > > * Uses *Java 8* as the baseline.
> > >
> > > * Upgrades to *Spring Framework 5.0 GA*.
> > >
> > > * Includes a new and very well-polished *Annotation-based configuration
> > > model* [4] for getting started with Apache Geode quickly and easily,
> > > especially when using *Spring Boot*.  You will find this [5], this [6]
> > > (DATAGEODE-33) and then this [7] (DATAGEODE-34) particularly
> interesting.
> > >
> > > * Improves support when using Apache Geode with other transactional
> > > resources in a JTA transaction by including *Annotation configuration
> for
> > > Geode's JCA Resource Adapter*; DATAGEODE-16. [8]
> > >
> > > * Adds support for conveniently enabling *client-side Security* when
> > > using the @EnableSecurity annotation, DATAGEODE-24 [9].  Some of you
> may
> > > remember this blog post [10] where I discussed SDG's support of Apache
> > > Geode's new *Integrated Security* framework, which focused on
> server-side
> > > Security. [11]  Now, the same annotation covers client-side Security as
> > > well [12].
> > >
> > > * Improves support of Apache Geode's *Continuous Query* feature using
> > > Annotations, DATAGEODE-38 [13], complete with associated documentation
> > > [14].  Works similarly to the core *Spring Framework's* POJO method
> > > annotated message listeners.
> > >
> > > One other notable is DATAGEODE-18 [15], which is *the making of a test
> > > framework* for greatly simplifying the development of both *Unit* and
> > *Integration
> > > Tests* for Apache Geode applications in a *Spring* context.  Every user
> > > here knows how daunting a task writing effective Unit/Integration tests
> > can
> > > be for Apache Geode; I have been doing this with GemFire/Geode (with
> > > *Spring*) for well over 6 years.
> > >
> > > The SDG testing framework aims to introduce new Annotations annotating
> > > your test classes that will help in simplifying mocking GemFire
> > components
> > > in *Unit Tests* and as well manage servers tied to the *Spring's*
> > > TestContext framework/container lifecycle inside your testing provider
> > > (e.g. *JUnit*) in client/server-based integration tests.
> > >
> > > For instance, here is 1 example [16] and an earlier preview of using
> the
> > > new @EnableGemFireMockObjects annotation in *Unit Tests*.
> > >
> > > For a complete list of changes in this release, have a look in the
> > > *changelog* [17].
> > >
> > > So many goodies to share, not enough time, so... expect a series of
> blog
> > > posts to follow and startup covering all the new developments in
> *Spring*
> > > on the Apache Geode front.
> > >
> > > I hope you will enjoy using all the new features in this release, and,
> as
> > > always, feedback is very much appreciated and welcomed.
> > >
> > > Stay tuned for more!  Until next time...
> > >
> > > Cheers!
> > > --
> > > -John
> > >
> > > [1] https://spring.io/blog/2017/10/02/spring-data-
> > > release-train-kay-goes-ga
> > > [2] https://github.com/spring-projects/spring-data-commons/
> > > wiki/Release-Train-Kay#participating-modules
> > > [3] http://projects.spring.io/spring-data/
> > > [4] https://docs.spring.io/spring-data/geode/docs/current/
> > reference/html/#
> > > bootstrap-annotation-config
> > > [5] https://docs.spring.io/spring-data/geode/docs/current/
> > reference/html/#
> > > bootstrap-annotation-config-regions
> > > [6] https://docs.spring.io/spring-data/geode/docs/current/
> > reference/html/#
> > > bootstrap-annotation-config-caching
> > > [7] https://docs.spring.io/spring-data/geode/docs/current/
> > reference/html/#
> > > bootstrap-annotation-config-cluster
> > > [8] https://jira.spring.io/browse/DATAGEODE-16
> > > [9] https://jira.spring.io/browse/DATAGEODE-24
> > >

Re: Rebase and squash before merging PRs

2017-10-05 Thread Galen O'Sullivan 
On Thu, Oct 5, 2017 at 3:14 PM, Jinmei Liao  wrote:

> Not sure if this is useful to everyone, but when I push a subsequent commit 
> to my feature branch, I always use "force push", so that it's only one commit 
> I need to rebase to develop.
>
>
I use force push when I've made small changes and don't have any big
reviews yet, but I generally prefer to keep the history in the PR until
merge so that myself and others can keep track of changesets, especially if
I want review again. I think it's largely personal preference.

[ANNOUNCE] Spring Session Data Geode 2.0.0.M2 Available...

2017-10-05 Thread John Blum 
Greetings Apache Geode Community-

I am pleased to announce 1 more release related to Apache Geode, *Spring
Session* for Apache Geode 2.0.0.M2 (milestone 2) is now available.

This release brings with some updates and improvements...

1. *Upgrades* to...

-- *Spring Framework* 5
-- *Spring Data* Kay-RELEASE
-- *Spring Session* 2.0.0.M4
-- *Spring Boot* 2.0.0.M4

2. Adds support for *PDX Serialization* [1], and...

3. Introduces a *new Serialization framework* [2] and (SessionSerializer)
interface allowing users to customize how an (HTTP) Session gets serialized
and persisted to Apache Geode.

See the official announcement [3] for more details.

#2 is the biggest change and 1 that users kept asking me for.  Now, PDX is
finally supported; yay!

The main benefit of using PDX is, you no longer need *Spring Session Data
Geode* or any of its transitive dependencies on the classpath of the
servers in your cluster.  In fact, you do not even need to put your
application domain objects stored in the Session and sent to Apache Geode
on the classpath of the servers, either.  You only need *Spring Session
Data Geode* on the classpath of your *Spring Boot*, *Spring Session*
enabled applications.

More details can be found in the *Spring Session Data Geode* *Reference
Guide*, starting here [4].

As always, any feedback is highly appreciated and welcomed.

Happy coding!

-- 
-John

[1]
https://docs.spring.io/autorepo/docs/spring-session-data-geode-build/2.0.0.M2/reference/htmlsingle/#httpsession-gemfire-serialization-spring-session
[2]
https://docs.spring.io/autorepo/docs/spring-session-data-geode-build/2.0.0.M2/reference/htmlsingle/#httpsession-gemfire-serialization-framework
[3]
https://spring.io/blog/2017/10/06/spring-session-data-geode-gemfire-2-0-0-m2-available
[4]
https://docs.spring.io/autorepo/docs/spring-session-data-geode-build/2.0.0.M2/reference/htmlsingle/#httpsession-gemfire-serialization

Re: Rebase and squash before merging PRs

2017-10-05 Thread Dave Barnes 
I like that idea - sounds comfortably similar to my pre-gitbox process.

On Thu, Oct 5, 2017 at 5:24 PM, Jacob Barrett  wrote:

> You can’t use the UI to just rebase. You would do that on your local repo
> and force push your branch. You could even take that time to squash
> yourself.
>
> Then the pull would show your new rebased commits for someone to approve
> and merge (squash too if they want).
>
> -Jake
>
>
> > On Oct 5, 2017, at 5:20 PM, Dave Barnes  wrote:
> >
> > Jake,
> > Say I have a PR with the original commit plus two more to incorporate
> > reviewer suggestions. How is it possible within the github UI to just
> > rebase without also merging? I don't see that choice in the gitbox
> pulldown
> > menu.
> >
> >> On Thu, Oct 5, 2017 at 4:59 PM, Jacob Barrett 
> wrote:
> >>
> >> If you want to preserve all commits use rebase and merge. If you want a
> >> single commit then use squash and merge, which rebases, squashes, and
> >> merges. Both options update the commit info with the person performing
> the
> >> merge.
> >>
> >> Personally though I think you should be asking contributors to rebase
> >> before you accept their pull so you know it has been vetted agains the
> >> latest develop changes. As committer you shouldn’t have to resolve a
> >> submitters trash. This makes merging safe too.
> >>
> >> -Jake
> >>
> >>
> >>> On Oct 5, 2017, at 4:32 PM, Nick Reich  wrote:
> >>>
> >>> Here are the docs from github:
> >>> https://help.github.com/articles/about-pull-request-merges/
> >>>
> >>> Based on those and using squash and commit for some of my merges, it
> >> looks
> >>> like it does what we want: just one commit for the merge of the feature
> >>> branch. Note that "rebase and merge" in github does not actually work
> >>> exactly like it does in git (see above link).
> >>>
>  On Thu, Oct 5, 2017 at 4:15 PM, Jared Stewart 
> >> wrote:
> 
>  Does anyone happen to know if “squash and merge” also does a rebase or
>  not? I’ve been hesitant to use that button since I’m not sure what
> exact
>  sequence of git commands it corresponds to.
> 
> > On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
> >
> > I think we can also use "squash and merge" if wanting to squash
> commits
> > before merging.  This would allow you not to have to force push every
>  time.
> >
> >> On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao 
> wrote:
> >>
> >> On the PR UI page, you can do that by pull down the the menu when
> you
>  are
> >> ready to merge. Remember to use "Rebase and merge".
> >>
> >>
> >> ​
> >>
> >> Not sure if this is useful to everyone, but when I push a subsequent
>  commit to my feature branch, I always use "force push", so that it's
> >> only
>  one commit I need to rebase to develop.
> >>
> >>
> >> On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart 
>  wrote:
> >>
> >>> I’ve been seeing a lot more merge commits on develop since we moved
> >> to
> >>> Gitbox.  Just wanted to give everyone a friendly reminder to please
>  rebase
> >>> before merging to keep our git history tidy and readable.
> >>>
> >>> Thanks,
> >>> Jared
> >>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> 
> 
> >>
>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Jacob Barrett 
You can’t use the UI to just rebase. You would do that on your local repo and 
force push your branch. You could even take that time to squash yourself. 

Then the pull would show your new rebased commits for someone to approve and 
merge (squash too if they want).

-Jake


> On Oct 5, 2017, at 5:20 PM, Dave Barnes  wrote:
> 
> Jake,
> Say I have a PR with the original commit plus two more to incorporate
> reviewer suggestions. How is it possible within the github UI to just
> rebase without also merging? I don't see that choice in the gitbox pulldown
> menu.
> 
>> On Thu, Oct 5, 2017 at 4:59 PM, Jacob Barrett  wrote:
>> 
>> If you want to preserve all commits use rebase and merge. If you want a
>> single commit then use squash and merge, which rebases, squashes, and
>> merges. Both options update the commit info with the person performing the
>> merge.
>> 
>> Personally though I think you should be asking contributors to rebase
>> before you accept their pull so you know it has been vetted agains the
>> latest develop changes. As committer you shouldn’t have to resolve a
>> submitters trash. This makes merging safe too.
>> 
>> -Jake
>> 
>> 
>>> On Oct 5, 2017, at 4:32 PM, Nick Reich  wrote:
>>> 
>>> Here are the docs from github:
>>> https://help.github.com/articles/about-pull-request-merges/
>>> 
>>> Based on those and using squash and commit for some of my merges, it
>> looks
>>> like it does what we want: just one commit for the merge of the feature
>>> branch. Note that "rebase and merge" in github does not actually work
>>> exactly like it does in git (see above link).
>>> 
 On Thu, Oct 5, 2017 at 4:15 PM, Jared Stewart 
>> wrote:
 
 Does anyone happen to know if “squash and merge” also does a rebase or
 not? I’ve been hesitant to use that button since I’m not sure what exact
 sequence of git commands it corresponds to.
 
> On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
> 
> I think we can also use "squash and merge" if wanting to squash commits
> before merging.  This would allow you not to have to force push every
 time.
> 
>> On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:
>> 
>> On the PR UI page, you can do that by pull down the the menu when you
 are
>> ready to merge. Remember to use "Rebase and merge".
>> 
>> 
>> ​
>> 
>> Not sure if this is useful to everyone, but when I push a subsequent
 commit to my feature branch, I always use "force push", so that it's
>> only
 one commit I need to rebase to develop.
>> 
>> 
>> On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart 
 wrote:
>> 
>>> I’ve been seeing a lot more merge commits on develop since we moved
>> to
>>> Gitbox.  Just wanted to give everyone a friendly reminder to please
 rebase
>>> before merging to keep our git history tidy and readable.
>>> 
>>> Thanks,
>>> Jared
>> 
>> 
>> 
>> 
>> --
>> Cheers
>> 
>> Jinmei
>> 
 
 
>>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Dave Barnes 
Jake,
Say I have a PR with the original commit plus two more to incorporate
reviewer suggestions. How is it possible within the github UI to just
rebase without also merging? I don't see that choice in the gitbox pulldown
menu.

On Thu, Oct 5, 2017 at 4:59 PM, Jacob Barrett  wrote:

> If you want to preserve all commits use rebase and merge. If you want a
> single commit then use squash and merge, which rebases, squashes, and
> merges. Both options update the commit info with the person performing the
> merge.
>
> Personally though I think you should be asking contributors to rebase
> before you accept their pull so you know it has been vetted agains the
> latest develop changes. As committer you shouldn’t have to resolve a
> submitters trash. This makes merging safe too.
>
> -Jake
>
>
> > On Oct 5, 2017, at 4:32 PM, Nick Reich  wrote:
> >
> > Here are the docs from github:
> > https://help.github.com/articles/about-pull-request-merges/
> >
> > Based on those and using squash and commit for some of my merges, it
> looks
> > like it does what we want: just one commit for the merge of the feature
> > branch. Note that "rebase and merge" in github does not actually work
> > exactly like it does in git (see above link).
> >
> >> On Thu, Oct 5, 2017 at 4:15 PM, Jared Stewart 
> wrote:
> >>
> >> Does anyone happen to know if “squash and merge” also does a rebase or
> >> not? I’ve been hesitant to use that button since I’m not sure what exact
> >> sequence of git commands it corresponds to.
> >>
> >>> On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
> >>>
> >>> I think we can also use "squash and merge" if wanting to squash commits
> >>> before merging.  This would allow you not to have to force push every
> >> time.
> >>>
>  On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:
> 
>  On the PR UI page, you can do that by pull down the the menu when you
> >> are
>  ready to merge. Remember to use "Rebase and merge".
> 
> 
>  ​
> 
>  Not sure if this is useful to everyone, but when I push a subsequent
> >> commit to my feature branch, I always use "force push", so that it's
> only
> >> one commit I need to rebase to develop.
> 
> 
>  On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart 
> >> wrote:
> 
> > I’ve been seeing a lot more merge commits on develop since we moved
> to
> > Gitbox.  Just wanted to give everyone a friendly reminder to please
> >> rebase
> > before merging to keep our git history tidy and readable.
> >
> > Thanks,
> > Jared
> 
> 
> 
> 
>  --
>  Cheers
> 
>  Jinmei
> 
> >>
> >>
>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Jacob Barrett 
If you want to preserve all commits use rebase and merge. If you want a single 
commit then use squash and merge, which rebases, squashes, and merges. Both 
options update the commit info with the person performing the merge. 

Personally though I think you should be asking contributors to rebase before 
you accept their pull so you know it has been vetted agains the latest develop 
changes. As committer you shouldn’t have to resolve a submitters trash. This 
makes merging safe too.

-Jake


> On Oct 5, 2017, at 4:32 PM, Nick Reich  wrote:
> 
> Here are the docs from github:
> https://help.github.com/articles/about-pull-request-merges/
> 
> Based on those and using squash and commit for some of my merges, it looks
> like it does what we want: just one commit for the merge of the feature
> branch. Note that "rebase and merge" in github does not actually work
> exactly like it does in git (see above link).
> 
>> On Thu, Oct 5, 2017 at 4:15 PM, Jared Stewart  wrote:
>> 
>> Does anyone happen to know if “squash and merge” also does a rebase or
>> not? I’ve been hesitant to use that button since I’m not sure what exact
>> sequence of git commands it corresponds to.
>> 
>>> On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
>>> 
>>> I think we can also use "squash and merge" if wanting to squash commits
>>> before merging.  This would allow you not to have to force push every
>> time.
>>> 
 On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:
 
 On the PR UI page, you can do that by pull down the the menu when you
>> are
 ready to merge. Remember to use "Rebase and merge".
 
 
 ​
 
 Not sure if this is useful to everyone, but when I push a subsequent
>> commit to my feature branch, I always use "force push", so that it's only
>> one commit I need to rebase to develop.
 
 
 On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart 
>> wrote:
 
> I’ve been seeing a lot more merge commits on develop since we moved to
> Gitbox.  Just wanted to give everyone a friendly reminder to please
>> rebase
> before merging to keep our git history tidy and readable.
> 
> Thanks,
> Jared
 
 
 
 
 --
 Cheers
 
 Jinmei
 
>> 
>>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Nick Reich 
Here are the docs from github:
https://help.github.com/articles/about-pull-request-merges/

Based on those and using squash and commit for some of my merges, it looks
like it does what we want: just one commit for the merge of the feature
branch. Note that "rebase and merge" in github does not actually work
exactly like it does in git (see above link).

On Thu, Oct 5, 2017 at 4:15 PM, Jared Stewart  wrote:

> Does anyone happen to know if “squash and merge” also does a rebase or
> not? I’ve been hesitant to use that button since I’m not sure what exact
> sequence of git commands it corresponds to.
>
> > On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
> >
> > I think we can also use "squash and merge" if wanting to squash commits
> > before merging.  This would allow you not to have to force push every
> time.
> >
> > On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:
> >
> >> On the PR UI page, you can do that by pull down the the menu when you
> are
> >> ready to merge. Remember to use "Rebase and merge".
> >>
> >>
> >> ​
> >>
> >> Not sure if this is useful to everyone, but when I push a subsequent
> commit to my feature branch, I always use "force push", so that it's only
> one commit I need to rebase to develop.
> >>
> >>
> >> On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart 
> wrote:
> >>
> >>> I’ve been seeing a lot more merge commits on develop since we moved to
> >>> Gitbox.  Just wanted to give everyone a friendly reminder to please
> rebase
> >>> before merging to keep our git history tidy and readable.
> >>>
> >>> Thanks,
> >>> Jared
> >>
> >>
> >>
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
>
>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Jared Stewart 
Does anyone happen to know if “squash and merge” also does a rebase or not? 
I’ve been hesitant to use that button since I’m not sure what exact sequence of 
git commands it corresponds to.

> On Oct 5, 2017, at 3:59 PM, Jason Huynh  wrote:
> 
> I think we can also use "squash and merge" if wanting to squash commits
> before merging.  This would allow you not to have to force push every time.
> 
> On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:
> 
>> On the PR UI page, you can do that by pull down the the menu when you are
>> ready to merge. Remember to use "Rebase and merge".
>> 
>> 
>> ​
>> 
>> Not sure if this is useful to everyone, but when I push a subsequent commit 
>> to my feature branch, I always use "force push", so that it's only one 
>> commit I need to rebase to develop.
>> 
>> 
>> On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart  wrote:
>> 
>>> I’ve been seeing a lot more merge commits on develop since we moved to
>>> Gitbox.  Just wanted to give everyone a friendly reminder to please rebase
>>> before merging to keep our git history tidy and readable.
>>> 
>>> Thanks,
>>> Jared
>> 
>> 
>> 
>> 
>> --
>> Cheers
>> 
>> Jinmei
>>

Re: Rebase and squash before merging PRs

2017-10-05 Thread Jason Huynh 
I think we can also use "squash and merge" if wanting to squash commits
before merging.  This would allow you not to have to force push every time.

On Thu, Oct 5, 2017 at 3:15 PM Jinmei Liao  wrote:

> On the PR UI page, you can do that by pull down the the menu when you are
> ready to merge. Remember to use "Rebase and merge".
>
>
> ​
>
> Not sure if this is useful to everyone, but when I push a subsequent commit 
> to my feature branch, I always use "force push", so that it's only one commit 
> I need to rebase to develop.
>
>
> On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart  wrote:
>
>> I’ve been seeing a lot more merge commits on develop since we moved to
>> Gitbox.  Just wanted to give everyone a friendly reminder to please rebase
>> before merging to keep our git history tidy and readable.
>>
>> Thanks,
>> Jared
>
>
>
>
> --
> Cheers
>
> Jinmei
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #700 was SUCCESSFUL (with 2182 tests). Change made by John Blum.

2017-10-05 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #700 was successful.
---
Scheduled with changes by John Blum.
2184 tests in total.

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




--
Code Changes
--
John Blum (cbf1b189168b7e05b49e3439b3fca9177843974e):

>DATAGEODE-47 - Add documentation in SDG's Reference Guide for the new 
>Annotation-based configuration model.



--
This message is automatically generated by Atlassian Bamboo

Re: Rebase and squash before merging PRs

2017-10-05 Thread Jinmei Liao 
On the PR UI page, you can do that by pull down the the menu when you are
ready to merge. Remember to use "Rebase and merge".


​

Not sure if this is useful to everyone, but when I push a subsequent
commit to my feature branch, I always use "force push", so that it's
only one commit I need to rebase to develop.


On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart  wrote:

> I’ve been seeing a lot more merge commits on develop since we moved to
> Gitbox.  Just wanted to give everyone a friendly reminder to please rebase
> before merging to keep our git history tidy and readable.
>
> Thanks,
> Jared




-- 
Cheers

Jinmei

Re: Rebase and squash before merging PRs

2017-10-05 Thread Mark Bretl 
One helpful Git configuration I use which can help reduce merge commits is
to set the default action to rebase when doing a pull. To set this a global
configuration default on your system, do the following command:

git config --global pull.rebase true

--Mark

On Thu, Oct 5, 2017 at 3:00 PM, Jared Stewart  wrote:

> I’ve been seeing a lot more merge commits on develop since we moved to
> Gitbox.  Just wanted to give everyone a friendly reminder to please rebase
> before merging to keep our git history tidy and readable.
>
> Thanks,
> Jared

Rebase and squash before merging PRs

2017-10-05 Thread Jared Stewart 
I’ve been seeing a lot more merge commits on develop since we moved to Gitbox.  
Just wanted to give everyone a friendly reminder to please rebase before 
merging to keep our git history tidy and readable.

Thanks,
Jared

Re: New client protocol configuration

2017-10-05 Thread William Markito Oliveira 
I was doing something similar to that for some other projects and found
that cfg4j [1] to be a very clean and good framework to keep the format of
the configuration generic and dynamic.  Built-in support for Yaml and
property files and can also ready from multiple sources like Git, Consul,
classpath or filesystem obviously, including merge of configuration files.

We actually started with Apache Commons [2] but decided to go cfg4j because
the API was a bit more clean, but both of them simplified a lot our
configuration efforts.

Just my 0.02c

[1] cfg4j.org/releases/latest/#tutorial
[2] https://commons.apache.org/proper/commons-configuration/

On Thu, Oct 5, 2017 at 3:34 PM, Mark Hanson  wrote:

> One thing also to consider if you modifying the config structure, is an
> evented config structure, so that registrants get callbacks if changes are
> made that are real-time.
>
> Thanks,
> Mark
> > On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan 
> wrote:
> >
> > I don't care too much about exactly what the configuration looks like,
> but
> > I want it to be unified, and I want it to be set when the cache starts.
> > Checking system properties throughout the codebase whenever we feel like
> is
> > a bit too magic for me.
> >
> > In addition, it seems that in order to add a new value to
> > DistributionConfig, I have to add it in several places. Config should be
> in
> > one place. Descriptions, values, ranges should be defined in one place
> and
> > Ideally it should be extendable, and it should have some checks to make
> it
> > hard to shoot yourself in the foot.
> >
> > For this particular problem, it turns out that we should not make it
> > configurable via a property, but should get this information from
> > SecurityService. I think that a unified config solution is something we
> > should look into for the future, though.
> >
> > -Galen
>
>


-- 
~/William

Re: New client protocol configuration

2017-10-05 Thread Mark Hanson 
One thing also to consider if you modifying the config structure, is an evented 
config structure, so that registrants get callbacks if changes are made that 
are real-time.

Thanks,
Mark
> On Oct 5, 2017, at 12:49 PM, Galen O'Sullivan  wrote:
> 
> I don't care too much about exactly what the configuration looks like, but
> I want it to be unified, and I want it to be set when the cache starts.
> Checking system properties throughout the codebase whenever we feel like is
> a bit too magic for me.
> 
> In addition, it seems that in order to add a new value to
> DistributionConfig, I have to add it in several places. Config should be in
> one place. Descriptions, values, ranges should be defined in one place and
> Ideally it should be extendable, and it should have some checks to make it
> hard to shoot yourself in the foot.
> 
> For this particular problem, it turns out that we should not make it
> configurable via a property, but should get this information from
> SecurityService. I think that a unified config solution is something we
> should look into for the future, though.
> 
> -Galen

Re: New client protocol configuration

2017-10-05 Thread Galen O'Sullivan 
I don't care too much about exactly what the configuration looks like, but
I want it to be unified, and I want it to be set when the cache starts.
Checking system properties throughout the codebase whenever we feel like is
a bit too magic for me.

In addition, it seems that in order to add a new value to
DistributionConfig, I have to add it in several places. Config should be in
one place. Descriptions, values, ranges should be defined in one place and
Ideally it should be extendable, and it should have some checks to make it
hard to shoot yourself in the foot.

For this particular problem, it turns out that we should not make it
configurable via a property, but should get this information from
SecurityService. I think that a unified config solution is something we
should look into for the future, though.

-Galen

Re: [ANNOUNCE] Spring Data Geode 2.0.0.RELEASE (Kay GA) Available...

2017-10-05 Thread Jagdish Mirani 
Cool - great progress John.
Jag

On Thu, Oct 5, 2017 at 10:51 AM, Michael Stolz  wrote:

> Wow! Great stuff John!
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
>
> On Thu, Oct 5, 2017 at 6:35 PM, John Blum  wrote:
>
> > Dear Geode Community-
> >
> > After almost 1 year of radio silence on all things related to *Spring
> > Data Geode* for Apache Geode, it is my pleasure to inform you that
> *Spring
> > Data Geode* *2.0.0.RELEASE* (Kay GA) is now available! [1]
> >
> > Many things have happened since my last announcement.
> >
> > First, *Spring Data Geode* 2.0 joins the *Spring Data Release Train* [2]
> > as another top-level *Spring Data* module in the *Spring Data* portfolio.
> > [3]  This is significant for few reasons, but most importantly, you can
> > expect a predictable and regular series of SDG releases going forward,
> and
> > announcement from me when they occur.
> >
> > Next, *Spring Data Geode* 2.0 encompasses some key updates...
> >
> > * Upgrades to *Apache Geode 1.2.1*.
> >
> > * Uses *Java 8* as the baseline.
> >
> > * Upgrades to *Spring Framework 5.0 GA*.
> >
> > * Includes a new and very well-polished *Annotation-based configuration
> > model* [4] for getting started with Apache Geode quickly and easily,
> > especially when using *Spring Boot*.  You will find this [5], this [6]
> > (DATAGEODE-33) and then this [7] (DATAGEODE-34) particularly interesting.
> >
> > * Improves support when using Apache Geode with other transactional
> > resources in a JTA transaction by including *Annotation configuration for
> > Geode's JCA Resource Adapter*; DATAGEODE-16. [8]
> >
> > * Adds support for conveniently enabling *client-side Security* when
> > using the @EnableSecurity annotation, DATAGEODE-24 [9].  Some of you may
> > remember this blog post [10] where I discussed SDG's support of Apache
> > Geode's new *Integrated Security* framework, which focused on server-side
> > Security. [11]  Now, the same annotation covers client-side Security as
> > well [12].
> >
> > * Improves support of Apache Geode's *Continuous Query* feature using
> > Annotations, DATAGEODE-38 [13], complete with associated documentation
> > [14].  Works similarly to the core *Spring Framework's* POJO method
> > annotated message listeners.
> >
> > One other notable is DATAGEODE-18 [15], which is *the making of a test
> > framework* for greatly simplifying the development of both *Unit* and
> *Integration
> > Tests* for Apache Geode applications in a *Spring* context.  Every user
> > here knows how daunting a task writing effective Unit/Integration tests
> can
> > be for Apache Geode; I have been doing this with GemFire/Geode (with
> > *Spring*) for well over 6 years.
> >
> > The SDG testing framework aims to introduce new Annotations annotating
> > your test classes that will help in simplifying mocking GemFire
> components
> > in *Unit Tests* and as well manage servers tied to the *Spring's*
> > TestContext framework/container lifecycle inside your testing provider
> > (e.g. *JUnit*) in client/server-based integration tests.
> >
> > For instance, here is 1 example [16] and an earlier preview of using the
> > new @EnableGemFireMockObjects annotation in *Unit Tests*.
> >
> > For a complete list of changes in this release, have a look in the
> > *changelog* [17].
> >
> > So many goodies to share, not enough time, so... expect a series of blog
> > posts to follow and startup covering all the new developments in *Spring*
> > on the Apache Geode front.
> >
> > I hope you will enjoy using all the new features in this release, and, as
> > always, feedback is very much appreciated and welcomed.
> >
> > Stay tuned for more!  Until next time...
> >
> > Cheers!
> > --
> > -John
> >
> > [1] https://spring.io/blog/2017/10/02/spring-data-
> > release-train-kay-goes-ga
> > [2] https://github.com/spring-projects/spring-data-commons/
> > wiki/Release-Train-Kay#participating-modules
> > [3] http://projects.spring.io/spring-data/
> > [4] https://docs.spring.io/spring-data/geode/docs/current/
> reference/html/#
> > bootstrap-annotation-config
> > [5] https://docs.spring.io/spring-data/geode/docs/current/
> reference/html/#
> > bootstrap-annotation-config-regions
> > [6] https://docs.spring.io/spring-data/geode/docs/current/
> reference/html/#
> > bootstrap-annotation-config-caching
> > [7] https://docs.spring.io/spring-data/geode/docs/current/
> reference/html/#
> > bootstrap-annotation-config-cluster
> > [8] https://jira.spring.io/browse/DATAGEODE-16
> > [9] https://jira.spring.io/browse/DATAGEODE-24
> > [10] https://spring.io/blog/2016/11/10/spring-data-geode-
> > 1-0-0-incubating-release-released
> > [11] https://docs.spring.io/spring-data/geode/docs/
> > current/reference/html/#bootstrap-annotation-config-security-server
> > [12] https://docs.spring.io/spring-data/geode/docs/
> > current/reference/html/#bootstrap-annotation-config-security-client
> > [13]

Re: [ANNOUNCE] Spring Data Geode 2.0.0.RELEASE (Kay GA) Available...

2017-10-05 Thread Udo Kohlmeyer 
NICE WORK John!!!

Always proactive and up-to-date as always!

--Udo

On Thu, Oct 5, 2017 at 10:35 AM, John Blum  wrote:

> Dear Geode Community-
>
> After almost 1 year of radio silence on all things related to *Spring
> Data Geode* for Apache Geode, it is my pleasure to inform you that *Spring
> Data Geode* *2.0.0.RELEASE* (Kay GA) is now available! [1]
>
> Many things have happened since my last announcement.
>
> First, *Spring Data Geode* 2.0 joins the *Spring Data Release Train* [2]
> as another top-level *Spring Data* module in the *Spring Data* portfolio.
> [3]  This is significant for few reasons, but most importantly, you can
> expect a predictable and regular series of SDG releases going forward, and
> announcement from me when they occur.
>
> Next, *Spring Data Geode* 2.0 encompasses some key updates...
>
> * Upgrades to *Apache Geode 1.2.1*.
>
> * Uses *Java 8* as the baseline.
>
> * Upgrades to *Spring Framework 5.0 GA*.
>
> * Includes a new and very well-polished *Annotation-based configuration
> model* [4] for getting started with Apache Geode quickly and easily,
> especially when using *Spring Boot*.  You will find this [5], this [6]
> (DATAGEODE-33) and then this [7] (DATAGEODE-34) particularly interesting.
>
> * Improves support when using Apache Geode with other transactional
> resources in a JTA transaction by including *Annotation configuration for
> Geode's JCA Resource Adapter*; DATAGEODE-16. [8]
>
> * Adds support for conveniently enabling *client-side Security* when
> using the @EnableSecurity annotation, DATAGEODE-24 [9].  Some of you may
> remember this blog post [10] where I discussed SDG's support of Apache
> Geode's new *Integrated Security* framework, which focused on server-side
> Security. [11]  Now, the same annotation covers client-side Security as
> well [12].
>
> * Improves support of Apache Geode's *Continuous Query* feature using
> Annotations, DATAGEODE-38 [13], complete with associated documentation
> [14].  Works similarly to the core *Spring Framework's* POJO method
> annotated message listeners.
>
> One other notable is DATAGEODE-18 [15], which is *the making of a test
> framework* for greatly simplifying the development of both *Unit* and 
> *Integration
> Tests* for Apache Geode applications in a *Spring* context.  Every user
> here knows how daunting a task writing effective Unit/Integration tests can
> be for Apache Geode; I have been doing this with GemFire/Geode (with
> *Spring*) for well over 6 years.
>
> The SDG testing framework aims to introduce new Annotations annotating
> your test classes that will help in simplifying mocking GemFire components
> in *Unit Tests* and as well manage servers tied to the *Spring's*
> TestContext framework/container lifecycle inside your testing provider
> (e.g. *JUnit*) in client/server-based integration tests.
>
> For instance, here is 1 example [16] and an earlier preview of using the
> new @EnableGemFireMockObjects annotation in *Unit Tests*.
>
> For a complete list of changes in this release, have a look in the
> *changelog* [17].
>
> So many goodies to share, not enough time, so... expect a series of blog
> posts to follow and startup covering all the new developments in *Spring*
> on the Apache Geode front.
>
> I hope you will enjoy using all the new features in this release, and, as
> always, feedback is very much appreciated and welcomed.
>
> Stay tuned for more!  Until next time...
>
> Cheers!
> --
> -John
>
> [1] https://spring.io/blog/2017/10/02/spring-data-
> release-train-kay-goes-ga
> [2] https://github.com/spring-projects/spring-data-commons/
> wiki/Release-Train-Kay#participating-modules
> [3] http://projects.spring.io/spring-data/
> [4] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap-annotation-config
> [5] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap-annotation-config-regions
> [6] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap-annotation-config-caching
> [7] https://docs.spring.io/spring-data/geode/docs/current/reference/html/#
> bootstrap-annotation-config-cluster
> [8] https://jira.spring.io/browse/DATAGEODE-16
> [9] https://jira.spring.io/browse/DATAGEODE-24
> [10] https://spring.io/blog/2016/11/10/spring-data-geode-
> 1-0-0-incubating-release-released
> [11] https://docs.spring.io/spring-data/geode/docs/
> current/reference/html/#bootstrap-annotation-config-security-server
> [12] https://docs.spring.io/spring-data/geode/docs/
> current/reference/html/#bootstrap-annotation-config-security-client
> [13] https://jira.spring.io/browse/DATAGEODE-38
> [14] https://docs.spring.io/spring-data/geode/docs/
> current/reference/html/#bootstrap-annotation-config-continuous-queries
> [15] https://jira.spring.io/browse/DATAGEODE-18
> [16] https://github.com/spring-projects/spring-data-
> geode/blob/master/src/test/java/org/springframework/data/gemfire/client/
>

[ANNOUNCE] Spring Data Geode 2.0.0.RELEASE (Kay GA) Available...

2017-10-05 Thread John Blum 
Dear Geode Community-

After almost 1 year of radio silence on all things related to *Spring Data
Geode* for Apache Geode, it is my pleasure to inform you that *Spring Data
Geode* *2.0.0.RELEASE* (Kay GA) is now available! [1]

Many things have happened since my last announcement.

First, *Spring Data Geode* 2.0 joins the *Spring Data Release Train* [2] as
another top-level *Spring Data* module in the *Spring Data* portfolio. [3]
 This is significant for few reasons, but most importantly, you can expect
a predictable and regular series of SDG releases going forward, and
announcement from me when they occur.

Next, *Spring Data Geode* 2.0 encompasses some key updates...

* Upgrades to *Apache Geode 1.2.1*.

* Uses *Java 8* as the baseline.

* Upgrades to *Spring Framework 5.0 GA*.

* Includes a new and very well-polished *Annotation-based configuration
model* [4] for getting started with Apache Geode quickly and easily,
especially when using *Spring Boot*.  You will find this [5], this [6]
(DATAGEODE-33) and then this [7] (DATAGEODE-34) particularly interesting.

* Improves support when using Apache Geode with other transactional
resources in a JTA transaction by including *Annotation configuration for
Geode's JCA Resource Adapter*; DATAGEODE-16. [8]

* Adds support for conveniently enabling *client-side Security* when using
the @EnableSecurity annotation, DATAGEODE-24 [9].  Some of you may remember
this blog post [10] where I discussed SDG's support of Apache Geode's
new *Integrated
Security* framework, which focused on server-side Security. [11]  Now, the
same annotation covers client-side Security as well [12].

* Improves support of Apache Geode's *Continuous Query* feature using
Annotations, DATAGEODE-38 [13], complete with associated documentation
[14].  Works similarly to the core *Spring Framework's* POJO method
annotated message listeners.

One other notable is DATAGEODE-18 [15], which is *the making of a test
framework* for greatly simplifying the development of both *Unit* and
*Integration
Tests* for Apache Geode applications in a *Spring* context.  Every user
here knows how daunting a task writing effective Unit/Integration tests can
be for Apache Geode; I have been doing this with GemFire/Geode (with
*Spring*) for well over 6 years.

The SDG testing framework aims to introduce new Annotations annotating your
test classes that will help in simplifying mocking GemFire components in *Unit
Tests* and as well manage servers tied to the *Spring's* TestContext
framework/container
lifecycle inside your testing provider (e.g. *JUnit*) in
client/server-based integration tests.

For instance, here is 1 example [16] and an earlier preview of using the
new @EnableGemFireMockObjects annotation in *Unit Tests*.

For a complete list of changes in this release, have a look in the
*changelog* [17].

So many goodies to share, not enough time, so... expect a series of blog
posts to follow and startup covering all the new developments in *Spring*
on the Apache Geode front.

I hope you will enjoy using all the new features in this release, and, as
always, feedback is very much appreciated and welcomed.

Stay tuned for more!  Until next time...

Cheers!
-- 
-John

[1] https://spring.io/blog/2017/10/02/spring-data-release-train-kay-goes-ga
[2]
https://github.com/spring-projects/spring-data-commons/wiki/Release-Train-Kay#participating-modules
[3] http://projects.spring.io/spring-data/
[4]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config
[5]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-regions
[6]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-caching
[7]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-cluster
[8] https://jira.spring.io/browse/DATAGEODE-16
[9] https://jira.spring.io/browse/DATAGEODE-24
[10]
https://spring.io/blog/2016/11/10/spring-data-geode-1-0-0-incubating-release-released
[11]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-security-server
[12]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-security-client
[13] https://jira.spring.io/browse/DATAGEODE-38
[14]
https://docs.spring.io/spring-data/geode/docs/current/reference/html/#bootstrap-annotation-config-continuous-queries
[15] https://jira.spring.io/browse/DATAGEODE-18
[16]
https://github.com/spring-projects/spring-data-geode/blob/master/src/test/java/org/springframework/data/gemfire/client/ClientCacheIntegrationTests.java
[17
https://docs.spring.io/spring-data/geode/docs/2.0.0.RELEASE/changelog.txt

Re: Looking for geode-core dunit using 5 dunit VMs

2017-10-05 Thread Barry Oglesby 
All of the WAN dunit tests use more than 5 VMS, but I'm not sure you want
those. Those are anything extending WANTestBase. I also see
LocatorDUnitTest testMultipleLocatorsRestartingAtSameTime does as well.

Thanks,
Barry Oglesby


On Thu, Oct 5, 2017 at 10:05 AM, Kirk Lund  wrote:

> I need help looking for a geode-core dunit test that is using 5 dunit VMs
> instead of 4. I want to review that test and then decide what to do with
> the DistributedTest framework tests that might run after it (the tests that
> verify that dunit itself is ok).
>
> This test is doing something like this:
>
> Host.getHost(0).getVM(4) <-- this is zero-based so it would cause dunit to
> create a 5th VM
>
> Thanks,
> Kirk
>

Re: Looking for geode-core dunit using 5 dunit VMs

2017-10-05 Thread Kirk Lund 
I found them (or some of them):

1) LocatorDUnitTest.testMultipleLocatorsRestartingAtSameTime() <- uses 5
VMs in addition to controller & locator
2)
LocatorDUnitTest.testMultipleLocatorsRestartingAtSameTimeWithMissingServers()
<- uses 5 VMs in addition to controller & locator
3)
PreferSerializedHARegionQueueTest.copyingHARegionQueueShouldNotThrowException()
<- uses 7 VMs in addition to controller & locator

I'll change the dunit infrastructure tests to get rid of any expectation of
4 default VMs since those tests may run after the above tests.

Thanks,
Kirk

On Thu, Oct 5, 2017 at 10:05 AM, Kirk Lund  wrote:

> I need help looking for a geode-core dunit test that is using 5 dunit VMs
> instead of 4. I want to review that test and then decide what to do with
> the DistributedTest framework tests that might run after it (the tests that
> verify that dunit itself is ok).
>
> This test is doing something like this:
>
> Host.getHost(0).getVM(4) <-- this is zero-based so it would cause dunit to
> create a 5th VM
>
> Thanks,
> Kirk
>

Looking for geode-core dunit using 5 dunit VMs

2017-10-05 Thread Kirk Lund 
I need help looking for a geode-core dunit test that is using 5 dunit VMs
instead of 4. I want to review that test and then decide what to do with
the DistributedTest framework tests that might run after it (the tests that
verify that dunit itself is ok).

This test is doing something like this:

Host.getHost(0).getVM(4) <-- this is zero-based so it would cause dunit to
create a 5th VM

Thanks,
Kirk

Re: [DISCUSS] Removal of "Submit an Issue" from Geode webpage

2017-10-05 Thread Dave Barnes 
Done.


On Mon, Oct 2, 2017 at 10:05 AM, Dave Barnes  wrote:

> Created GEODE-3726 (https://issues.apache.org/jira/browse/GEODE-3726)
>
> On Mon, Oct 2, 2017 at 9:07 AM, Dave Barnes  wrote:
>
>> I volunteer to handle this, beginning with a JIRA ticket.
>> I'm not sure we need to add any text anywhere. On the Geode home page
>> there's a button for "ask a question on the Mailing LIsts", though it is
>> located below the fold.
>>
>> On Mon, Oct 2, 2017 at 8:59 AM, Alexander Murmann 
>> wrote:
>>
>>> +1 for moving them to the mailing list
>>>
>>> On Fri, Sep 29, 2017 at 8:41 PM, Mark Bretl  wrote:
>>>
>>> > +1 for removal
>>> >
>>> > —Mark
>>> >
>>> > On Fri, Sep 29, 2017 at 1:17 PM Gregory Chase 
>>> wrote:
>>> >
>>> > > Yes please, especially since I'm not the one posting these :)
>>> > >
>>> > > On Fri, Sep 29, 2017 at 11:35 AM, Dave Barnes 
>>> > wrote:
>>> > >
>>> > > > +1 to removing the button.
>>> > > > +1 to Dan's suggestion of nudging users toward the mailing list.  I
>>> > see a
>>> > > > place we could add a few words on the Community page, where the
>>> Users
>>> > > > mailing list is the first entry; add to the blurb "or raise an
>>> issue".
>>> > > (The
>>> > > > Mailing Lists menu choice takes you here, as well.)
>>> > > >
>>> > > >
>>> > > > On Fri, Sep 29, 2017 at 11:15 AM, Dan Smith 
>>> wrote:
>>> > > >
>>> > > > > +1 - I think it would be better to just encourage users to send
>>> > > > > issues/questions to the users list initially.
>>> > > > >
>>> > > > > -Dan
>>> > > > >
>>> > > > > On Fri, Sep 29, 2017 at 11:08 AM, Michael William Dodge
>>> > > > >  wrote:
>>> > > > > > +1 to improving the signal-to-noise ratio
>>> > > > > >
>>> > > > > >> On 29 Sep, 2017, at 11:07, Jason Huynh 
>>> wrote:
>>> > > > > >>
>>> > > > > >> GEODE-3280
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Greg Chase
>>> > >
>>> > > Product team, Pivotal Cloud Foundry Services
>>> > > https://pivotal.io/platform/services >> >
>>> > >
>>> > > Pivotal Software
>>> > > http://www.pivotal.io/
>>> > >
>>> > > 650-215-0477
>>> > > @GregChase
>>> > >
>>> >
>>>
>>
>>
>