You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Mark Hanson <mh...@pivotal.io> on 2019/11/26 05:13:02 UTC
[VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Hello Geode Dev Community,
This is a release candidate for Apache Geode version 1.11.0.RC3.
Thanks to all the community members for their contributions to this release!
Please do a review and give your feedback, including the checks you performed.
Voting deadline:
11AM PST Monday December 2 2019.
Please note that we are voting upon the source tag:
rel/v1.11.0.RC3
Release notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
Source and binary distributions:
https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
Maven staging repo:
https://repository.apache.org/content/repositories/orgapachegeode-1063
GitHub:
https://github.com/apache/geode/tree/rel/v1.11.0.RC3
https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
Pipelines:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
Geode's KEYS file containing PGP keys we use to sign the release:
https://github.com/apache/geode/blob/develop/KEYS
Command to run geode-examples:
./gradlew -PgeodeReleaseUrl=https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3 -PgeodeRepositoryUrl=https://repository.apache.org/content/repositories/orgapachegeode-1063 build runAll
Regards
Mark Hanson
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Dec 4, 2019, at 9:24 AM, John Blum <jb...@pivotal.io> wrote:
>
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs. It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization to
> even build a project (application, framework or otherwise) using those
> classes with Apache Geode.
For those internal classes you use perhaps you can provide an RFC to move them to or augment the public API? If external things need them we should find a more elegant way to do this than chasing changing internals.
-Jake
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I'm working on this right now.. Will submit a PR for GEODE-7531 and
GEODE-7159 (it is the similar change than 7531) shortly.
--Udo
On 12/16/19 2:45 PM, Owen Nichols wrote:
> Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting it…by the end of this week if possible?
>
>> On Dec 11, 2019, at 4:19 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>> Hi All,
>>
>> It does not look like we have an assignee for GEODE-7531. Any takers?
>>
>> Thanks,
>> Mark
>>
>>> On Dec 4, 2019, at 2:35 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>
>>> So, outstanding issues that I see right now are
>>>
>>> GEODE-7531
>>> GEODE-7537
>>> GEODE-7538
>>>
>>> Thanks,
>>> Mark
>>>
>>>> On Dec 4, 2019, at 2:11 PM, John Blum <jb...@pivotal.io> wrote:
>>>>
>>>> This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
>>>> (and all tests pass), as I indicated above in my origin +0 vote.
>>>>
>>>> This is a definitive problem for SBDG when using STDG to mock Apache Geode
>>>> resources/objects, which is caused by GEODE-7531.
>>>>
>>>> Either way, the design/code changes made in GEODE-6759 were poor and should
>>>> be fixed regardless which GEODE-7531 describes.
>>>>
>>>> -j
>>>>
>>>>
>>>> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <ds...@pivotal.io> wrote:
>>>>
>>>>> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
>>>>>
>>>>>> I am changing my vote to -1!
>>>>>>
>>>>>> I have filed GEODE-7531 <
>>>>> https://issues.apache.org/jira/browse/GEODE-7531>
>>>>>> [1],
>>>>>> which is a serious blocking issue for all things *Spring* for Apache
>>>>>> Geode. This issue alone is currently preventing me from upgrading
>>>>> *Spring
>>>>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
>>>>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
>>>>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
>>>>> soon
>>>>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>>>>>>
>>>>>
>>>>> I commented on the above JIRA. While we definitely don't want to break
>>>>> spring data geode, it looks like maybe the issue is just with one unit test
>>>>> in Spring Data Geode using an internal geode API to inject something into a
>>>>> singleton? If that's the case, I think it would be better to fix that one
>>>>> test in SDG.
>>>>>
>>>>> -Dan
>>>>>
>>>>
>>>> --
>>>> -John
>>>> Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Owen Nichols <on...@pivotal.io>.
Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting it…by the end of this week if possible?
> On Dec 11, 2019, at 4:19 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> Hi All,
>
> It does not look like we have an assignee for GEODE-7531. Any takers?
>
> Thanks,
> Mark
>
>> On Dec 4, 2019, at 2:35 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>> So, outstanding issues that I see right now are
>>
>> GEODE-7531
>> GEODE-7537
>> GEODE-7538
>>
>> Thanks,
>> Mark
>>
>>> On Dec 4, 2019, at 2:11 PM, John Blum <jb...@pivotal.io> wrote:
>>>
>>> This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
>>> (and all tests pass), as I indicated above in my origin +0 vote.
>>>
>>> This is a definitive problem for SBDG when using STDG to mock Apache Geode
>>> resources/objects, which is caused by GEODE-7531.
>>>
>>> Either way, the design/code changes made in GEODE-6759 were poor and should
>>> be fixed regardless which GEODE-7531 describes.
>>>
>>> -j
>>>
>>>
>>> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <ds...@pivotal.io> wrote:
>>>
>>>> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
>>>>
>>>>> I am changing my vote to -1!
>>>>>
>>>>> I have filed GEODE-7531 <
>>>> https://issues.apache.org/jira/browse/GEODE-7531>
>>>>> [1],
>>>>> which is a serious blocking issue for all things *Spring* for Apache
>>>>> Geode. This issue alone is currently preventing me from upgrading
>>>> *Spring
>>>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
>>>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
>>>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
>>>> soon
>>>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>>>>>
>>>>
>>>>
>>>> I commented on the above JIRA. While we definitely don't want to break
>>>> spring data geode, it looks like maybe the issue is just with one unit test
>>>> in Spring Data Geode using an internal geode API to inject something into a
>>>> singleton? If that's the case, I think it would be better to fix that one
>>>> test in SDG.
>>>>
>>>> -Dan
>>>>
>>>
>>>
>>> --
>>> -John
>>> Spring Data Team
>>
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Mark Hanson <mh...@pivotal.io>.
Hi All,
It does not look like we have an assignee for GEODE-7531. Any takers?
Thanks,
Mark
> On Dec 4, 2019, at 2:35 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> So, outstanding issues that I see right now are
>
> GEODE-7531
> GEODE-7537
> GEODE-7538
>
> Thanks,
> Mark
>
>> On Dec 4, 2019, at 2:11 PM, John Blum <jb...@pivotal.io> wrote:
>>
>> This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
>> (and all tests pass), as I indicated above in my origin +0 vote.
>>
>> This is a definitive problem for SBDG when using STDG to mock Apache Geode
>> resources/objects, which is caused by GEODE-7531.
>>
>> Either way, the design/code changes made in GEODE-6759 were poor and should
>> be fixed regardless which GEODE-7531 describes.
>>
>> -j
>>
>>
>> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <ds...@pivotal.io> wrote:
>>
>>> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
>>>
>>>> I am changing my vote to -1!
>>>>
>>>> I have filed GEODE-7531 <
>>> https://issues.apache.org/jira/browse/GEODE-7531>
>>>> [1],
>>>> which is a serious blocking issue for all things *Spring* for Apache
>>>> Geode. This issue alone is currently preventing me from upgrading
>>> *Spring
>>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
>>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
>>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
>>> soon
>>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>>>>
>>>
>>>
>>> I commented on the above JIRA. While we definitely don't want to break
>>> spring data geode, it looks like maybe the issue is just with one unit test
>>> in Spring Data Geode using an internal geode API to inject something into a
>>> singleton? If that's the case, I think it would be better to fix that one
>>> test in SDG.
>>>
>>> -Dan
>>>
>>
>>
>> --
>> -John
>> Spring Data Team
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Mark Hanson <mh...@pivotal.io>.
So, outstanding issues that I see right now are
GEODE-7531
GEODE-7537
GEODE-7538
Thanks,
Mark
> On Dec 4, 2019, at 2:11 PM, John Blum <jb...@pivotal.io> wrote:
>
> This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
> (and all tests pass), as I indicated above in my origin +0 vote.
>
> This is a definitive problem for SBDG when using STDG to mock Apache Geode
> resources/objects, which is caused by GEODE-7531.
>
> Either way, the design/code changes made in GEODE-6759 were poor and should
> be fixed regardless which GEODE-7531 describes.
>
> -j
>
>
> On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <ds...@pivotal.io> wrote:
>
>> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
>>
>>> I am changing my vote to -1!
>>>
>>> I have filed GEODE-7531 <
>> https://issues.apache.org/jira/browse/GEODE-7531>
>>> [1],
>>> which is a serious blocking issue for all things *Spring* for Apache
>>> Geode. This issue alone is currently preventing me from upgrading
>> *Spring
>>> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
>>> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
>>> Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
>> soon
>>> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>>>
>>
>>
>> I commented on the above JIRA. While we definitely don't want to break
>> spring data geode, it looks like maybe the issue is just with one unit test
>> in Spring Data Geode using an internal geode API to inject something into a
>> singleton? If that's the case, I think it would be better to fix that one
>> test in SDG.
>>
>> -Dan
>>
>
>
> --
> -John
> Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Dan Smith <ds...@pivotal.io>.
I had a side conversation with John. I created a proposal in a separate and
a JIRA (GEODE-7555) for what I think is a good long term solution to the
issues STDG had mocking the Geode API.
In the short term, I'm fine with whatever we decide we should do to support
STDG.
-Dan
On Thu, Dec 5, 2019 at 11:36 AM Anilkumar Gingade <ag...@pivotal.io>
wrote:
> Trying to get a conclusion out of it:
> - The SDG/STDG to address the issue by changing the code on its part
> - Create JIRA ticket for the issue raised. And prioritize/work the issue in
> coming GEODE release.
>
> -Anil.
>
>
> On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols <on...@pivotal.io> wrote:
>
> > > On Dec 4, 2019, at 10:09 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >
> > > I think we can tone down the inflammatory statements
> >
> > Jake, thank you for speaking up, I felt the same way but wasn’t sure how
> > to say it.
> >
> > This might be a good opportunity for all of us to review the
> > https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Anilkumar Gingade <ag...@pivotal.io>.
Trying to get a conclusion out of it:
- The SDG/STDG to address the issue by changing the code on its part
- Create JIRA ticket for the issue raised. And prioritize/work the issue in
coming GEODE release.
-Anil.
On Thu, Dec 5, 2019 at 10:12 AM Owen Nichols <on...@pivotal.io> wrote:
> > On Dec 4, 2019, at 10:09 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I think we can tone down the inflammatory statements
>
> Jake, thank you for speaking up, I felt the same way but wasn’t sure how
> to say it.
>
> This might be a good opportunity for all of us to review the
> https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Owen Nichols <on...@pivotal.io>.
> On Dec 4, 2019, at 10:09 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I think we can tone down the inflammatory statements
Jake, thank you for speaking up, I felt the same way but wasn’t sure how to say it.
This might be a good opportunity for all of us to review the https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Dan Smith <ds...@pivotal.io>.
+1 to what Jake said.
-Dan
On Wed, Dec 4, 2019 at 11:32 PM Owen Nichols <on...@pivotal.io> wrote:
> +1 for a short-term solution in 1.11 while we discuss a more complete
> proposal for 1.12
>
> On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
> > I think we can tone down the inflammatory statements. It is well
> > established that, like any legacy code base, Geode has issues. One of
> them
> > is a less than ideal set of APIs for certain tasks. Whatever the issues
> > were in the past with getting APIs adjusted to suit the SDG project
> should
> > be left in the past and we can work forward on a new strategy.
> >
> > The term public API is redundant, if its designated API then it is
> public.
> > Let’s also be clear that "internal API” is not a thing, if it is internal
> > it is not an API. The language semantics of public/private are not what
> > defines and API. As such, relying on internal classes tor work around
> > deficiencies in a API is dangerous and should only be done as a stopgap
> > measure while addressing the API’s deficiency. Java, up until 9, lacked
> any
> > clear distinction of internals vs API so, like many projects, Geode chose
> > the “internal” package name to denote things that are not to be consume
> as
> > API. As we go forward with Java 9 modules support these will be enforced
> by
> > the runtime and compilers.
> >
> > A JIRA should be opened to address the API deficiency. When the API is
> > enhanced then the internal class usage should be replaced immediately
> with
> > the API. It is unreasonable to expect an upstream project to maintain
> > internal classes as though they are API or expect them to address
> > deficiencies in the API if they are not communicated. It is also
> > unreasonable for the upstream project to ignore obvious deficiencies in
> its
> > APIs and should use these issues raised by downstream projects to
> > prioritize improvements. Work needs to be done on both these projects to
> > make improvements.
> >
> > To resolve the issues raised below let’s get some JIRAs and/or RFCs
> opened
> > to address the APIs the SDG needs to work. Let’s work to burn down this
> > debt of internal class usage in SDG to avoid issues like this in the
> > future. I am sure we can figure out a short term solution to address the
> > immediate compile issues, whether that’s making a unit test into an
> > integration test, refactoring the internals to not blindly cast, or
> > whatever. We can then work out a strategy to address this the correct way
> > in the develop branch for 1.12.
> >
> > -Jake
> >
> >
> >
> > > On Dec 4, 2019, at 6:20 PM, John Blum <jb...@pivotal.io> wrote:
> > >
> > > If you must know, there are important test cases in both SBDG and SSDG
> to
> > > be able to register (and subsequently unregister) the "mock" Pool with
> > the
> > > PoolManager, which unfortunately is a consequence of the SDG
> > > PoolFactoryBean's design being reliant on the PoolManager (to resolve
> the
> > > Pool), and to some extent, the PoolFactory API (to create the Pool) in
> > the
> > > first place. Of course, there is no other way to "resolve" a reference
> > to
> > > a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
> > >
> > > Unfortunately, STDG (or SDG) would not need to import "internal" APIs
> if
> > > Apache Geode's public API was properly maintained and evolved to
> address
> > a
> > > new use cases. For example (and again), see GEODE-7532
> > > <https://issues.apache.org/jira/browse/GEODE-7532> [1].
> > >
> > > It turns out, there are many, many cases like GEODE-7532
> > > <https://issues.apache.org/jira/browse/GEODE-7532> [1], with classes
> and
> > > methods containing useful functions buried deep down inside Geode
> > > "internal" packages. The o.a.g.distributed.internal.MemberListener
> > > interface comes to mind. It is not difficult to see how his interface
> > > would be useful in both frameworks & tooling (e.g. for management &
> > > monitoring).
> > >
> > > Or, how about the poor resource management/cleanup Apache Geode fails
> to
> > do
> > > properly w.r.t. SSL Sockets, that STDG now needs to account for
> > > <
> >
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> > >
> > > [2]
> > > when running automated integration tests.
> > >
> > > I think there was another example
> > > <https://markmail.org/message/5juxxnkttzjndidg> [3] recently, which
> STDG
> > > must account for <https://markmail.org/message/5juxxnkttzjndidg> [4]
> as
> > > well.
> > >
> > > Serializer registration/unregistration is yet another area. The
> laundry
> > > list is quite long!
> > >
> > > The whole notion of Apache Geode's "internal" API is horribly broken,
> > > especially when the public API often comes up short.
> > >
> > > What troubles me is that we see the recommended changes in GEODE-7532
> as
> > a
> > > "bandaid". Really?
> > >
> > > It does not matter whether these classes are "internal" or not, nor
> > whether
> > > they are used (externally) or not, so long as they are used properly.
> If
> > > they are "public" there is simply no guarantee they won't be used, and
> > you
> > > cannot expect "internal" problems to not have external consequences.
> > >
> > > SIDE NOTE: Of course, this is further predicated on the fact those
> > > "internal" classes were designed/implemented correctly in the first
> > place,
> > > which they also, were not!
> > >
> > > I down voted for several reasons:
> > >
> > > 1. First, YES, because this blocks SBDG from moving to Apache Geode
> 1.11,
> > > and perhaps, more importantly...
> > > 2. Because the Pool management in PoolManagerImpl A) refers to the Pool
> > as
> > > PoolImpl despite taking a reference to Pool, and B) exposes the
> > > implementation of the usage tracking logic (which is a clear violation
> of
> > > "encapsulation" and a series code smell)
> > > 3. And because the IllegalStateException message is not accurate nor
> was
> > it
> > > very informative (e.g. "what Regions").
> > > 4. Or because 2A by (along with GEODE-7159
> > > <https://issues.apache.org/jira/browse/GEODE-7159> [5]) will most
> > > definitely cause problems for us later, especially since these problems
> > > will be time delayed (invoked during resource cleanup) making them hard
> > to
> > > pinpoint and very confusing to users.
> > >
> > > Also, imagine a scenario where Geode offers different Pool
> > implementations,
> > > beyond PoolImpl. Why else would Geode provide a PoolFactory interface
> if
> > > not to encapsulate creation, configuration and initialization of
> > different
> > > types of Pools.... part of that *Open/Closed* principle. There is no
> > point
> > > to have a PoolFactory otherwise since the PoolManager could have simply
> > > created Pools. Ironically, the PoolFactory is not something that is
> used
> > > in this way and therefore became an unnecessary layer of indirection.
> > #sigh
> > >
> > > In addition, the recommended changes in GEODE-7531 are not invasive
> > > what-so-ever, and will not adversely affect Geode 1 way or another.
> > >
> > > In closing, anytime the overall code quality of Geode comes into
> question
> > > (and there is a lot to question with this codebase), which can, and
> most
> > > likely will affect our end-users experience, and it HAS and DOES, you
> > > better believe and I am going to call this out.
> > >
> > > -j
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/GEODE-7532
> > > [2]
> > >
> >
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> > > [3] https://markmail.org/message/5juxxnkttzjndidg
> > > [4] https://markmail.org/message/5juxxnkttzjndidg
> > > [5] https://issues.apache.org/jira/browse/GEODE-7159
> > >
> > > On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton <rh...@pivotal.io>
> > wrote:
> > >
> > >> @udo, if one needs to use a strong word like 'offender', then the
> > offender
> > >> is the one using an internal API. Geode is under no obligation to
> > maintain
> > >> or "fix" these for any project.
> > >>
> > >> Is there a Jira, github issue, or pull-request to promote the internal
> > >> class to the public space? Is there a feature request to uncouple this
> > >> class you want to use in Spring?
> > >>
> > >> Is Spring the tail wagging the dog for Geode releases?
> > >>
> > >>
> > >> On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <ud...@apache.com> wrote:
> > >>
> > >>> @Dan,
> > >>>
> > >>> I will add my -1 to this.
> > >>>
> > >>> I understand your argument of "let's solve the problem by removing
> the
> > >>> offender".
> > >>>
> > >>> But in reality who is the offender? Is it the one class that is using
> > an
> > >>> "internal" api OR is it the implementation itself that is to tightly
> > >>> coupled that extending it is impossible?
> > >>>
> > >>> STDG right now is trying to create a test, to test functionality that
> > >>> requires it to inject/mock a Pool. The smallest piece of the code,
> not
> > >>> the WHOLE PoolManager. But the system does not allow for the
> injection
> > >>> of a `Pool` (which btw all the methods on the `PoolManagerImpl` has
> as
> > >>> arguments). It casts every generic `Pool` to its implementation. This
> > is
> > >>> a very limiting factor.
> > >>>
> > >>> I understand that delaying a release is not optimal, but how much
> > effort
> > >>> to we believe it to be to clean up the code that so tightly couples
> > >>> implementations together.
> > >>>
> > >>> I think we also must not forget that John, like many of us, is a
> > >>> committer and PMC member on Geode. He also happens to be the main
> > >>> committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
> > >>> should not go out without fixing a limiting feature to the Geode
> > >>> project, then he may do so.
> > >>>
> > >>> I also feel that this is a limiting factor.
> > >>>
> > >>> The only difference is that I am not the main committer on the Spring
> > >>> data projects for Geode. John is merely trying to get the best
> outcome
> > >>> for both projects.
> > >>>
> > >>> --Udo
> > >>>
> > >>> On 12/4/19 4:39 PM, Dan Smith wrote:
> > >>>>> Quite frankly the reasons STDG (or dependent projects downstream
> like
> > >>> SDG,
> > >>>>> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to
> > >> point
> > >>>>> articulated in the description of GEODE-753.
> > >>>>>
> > >>>> What bothers me here is not your suggestions in GEODE-1753, but the
> > >> fact
> > >>>> that you are vetoing a Geode release because STDG is using an
> internal
> > >>>> Geode method and had a problem.
> > >>>>
> > >>>> How hard is it to remove the use of PoolManagerImpl from STDG? If we
> > >> can
> > >>>> fix the issue there, that seems better than putting bandaids into
> the
> > >>>> release branch so STDG can continue to use internal APIs.
> > >>>>
> > >>>> -Dan
> > >>>>
> > >>>
> > >>
> > >
> > >
> > > --
> > > -John
> > > Spring Data Team
> >
> >
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Owen Nichols <on...@pivotal.io>.
+1 for a short-term solution in 1.11 while we discuss a more complete
proposal for 1.12
On Wed, Dec 4, 2019 at 10:09 PM Jacob Barrett <jb...@pivotal.io> wrote:
> I think we can tone down the inflammatory statements. It is well
> established that, like any legacy code base, Geode has issues. One of them
> is a less than ideal set of APIs for certain tasks. Whatever the issues
> were in the past with getting APIs adjusted to suit the SDG project should
> be left in the past and we can work forward on a new strategy.
>
> The term public API is redundant, if its designated API then it is public.
> Let’s also be clear that "internal API” is not a thing, if it is internal
> it is not an API. The language semantics of public/private are not what
> defines and API. As such, relying on internal classes tor work around
> deficiencies in a API is dangerous and should only be done as a stopgap
> measure while addressing the API’s deficiency. Java, up until 9, lacked any
> clear distinction of internals vs API so, like many projects, Geode chose
> the “internal” package name to denote things that are not to be consume as
> API. As we go forward with Java 9 modules support these will be enforced by
> the runtime and compilers.
>
> A JIRA should be opened to address the API deficiency. When the API is
> enhanced then the internal class usage should be replaced immediately with
> the API. It is unreasonable to expect an upstream project to maintain
> internal classes as though they are API or expect them to address
> deficiencies in the API if they are not communicated. It is also
> unreasonable for the upstream project to ignore obvious deficiencies in its
> APIs and should use these issues raised by downstream projects to
> prioritize improvements. Work needs to be done on both these projects to
> make improvements.
>
> To resolve the issues raised below let’s get some JIRAs and/or RFCs opened
> to address the APIs the SDG needs to work. Let’s work to burn down this
> debt of internal class usage in SDG to avoid issues like this in the
> future. I am sure we can figure out a short term solution to address the
> immediate compile issues, whether that’s making a unit test into an
> integration test, refactoring the internals to not blindly cast, or
> whatever. We can then work out a strategy to address this the correct way
> in the develop branch for 1.12.
>
> -Jake
>
>
>
> > On Dec 4, 2019, at 6:20 PM, John Blum <jb...@pivotal.io> wrote:
> >
> > If you must know, there are important test cases in both SBDG and SSDG to
> > be able to register (and subsequently unregister) the "mock" Pool with
> the
> > PoolManager, which unfortunately is a consequence of the SDG
> > PoolFactoryBean's design being reliant on the PoolManager (to resolve the
> > Pool), and to some extent, the PoolFactory API (to create the Pool) in
> the
> > first place. Of course, there is no other way to "resolve" a reference
> to
> > a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
> >
> > Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
> > Apache Geode's public API was properly maintained and evolved to address
> a
> > new use cases. For example (and again), see GEODE-7532
> > <https://issues.apache.org/jira/browse/GEODE-7532> [1].
> >
> > It turns out, there are many, many cases like GEODE-7532
> > <https://issues.apache.org/jira/browse/GEODE-7532> [1], with classes and
> > methods containing useful functions buried deep down inside Geode
> > "internal" packages. The o.a.g.distributed.internal.MemberListener
> > interface comes to mind. It is not difficult to see how his interface
> > would be useful in both frameworks & tooling (e.g. for management &
> > monitoring).
> >
> > Or, how about the poor resource management/cleanup Apache Geode fails to
> do
> > properly w.r.t. SSL Sockets, that STDG now needs to account for
> > <
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> >
> > [2]
> > when running automated integration tests.
> >
> > I think there was another example
> > <https://markmail.org/message/5juxxnkttzjndidg> [3] recently, which STDG
> > must account for <https://markmail.org/message/5juxxnkttzjndidg> [4] as
> > well.
> >
> > Serializer registration/unregistration is yet another area. The laundry
> > list is quite long!
> >
> > The whole notion of Apache Geode's "internal" API is horribly broken,
> > especially when the public API often comes up short.
> >
> > What troubles me is that we see the recommended changes in GEODE-7532 as
> a
> > "bandaid". Really?
> >
> > It does not matter whether these classes are "internal" or not, nor
> whether
> > they are used (externally) or not, so long as they are used properly. If
> > they are "public" there is simply no guarantee they won't be used, and
> you
> > cannot expect "internal" problems to not have external consequences.
> >
> > SIDE NOTE: Of course, this is further predicated on the fact those
> > "internal" classes were designed/implemented correctly in the first
> place,
> > which they also, were not!
> >
> > I down voted for several reasons:
> >
> > 1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
> > and perhaps, more importantly...
> > 2. Because the Pool management in PoolManagerImpl A) refers to the Pool
> as
> > PoolImpl despite taking a reference to Pool, and B) exposes the
> > implementation of the usage tracking logic (which is a clear violation of
> > "encapsulation" and a series code smell)
> > 3. And because the IllegalStateException message is not accurate nor was
> it
> > very informative (e.g. "what Regions").
> > 4. Or because 2A by (along with GEODE-7159
> > <https://issues.apache.org/jira/browse/GEODE-7159> [5]) will most
> > definitely cause problems for us later, especially since these problems
> > will be time delayed (invoked during resource cleanup) making them hard
> to
> > pinpoint and very confusing to users.
> >
> > Also, imagine a scenario where Geode offers different Pool
> implementations,
> > beyond PoolImpl. Why else would Geode provide a PoolFactory interface if
> > not to encapsulate creation, configuration and initialization of
> different
> > types of Pools.... part of that *Open/Closed* principle. There is no
> point
> > to have a PoolFactory otherwise since the PoolManager could have simply
> > created Pools. Ironically, the PoolFactory is not something that is used
> > in this way and therefore became an unnecessary layer of indirection.
> #sigh
> >
> > In addition, the recommended changes in GEODE-7531 are not invasive
> > what-so-ever, and will not adversely affect Geode 1 way or another.
> >
> > In closing, anytime the overall code quality of Geode comes into question
> > (and there is a lot to question with this codebase), which can, and most
> > likely will affect our end-users experience, and it HAS and DOES, you
> > better believe and I am going to call this out.
> >
> > -j
> >
> >
> > [1] https://issues.apache.org/jira/browse/GEODE-7532
> > [2]
> >
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> > [3] https://markmail.org/message/5juxxnkttzjndidg
> > [4] https://markmail.org/message/5juxxnkttzjndidg
> > [5] https://issues.apache.org/jira/browse/GEODE-7159
> >
> > On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton <rh...@pivotal.io>
> wrote:
> >
> >> @udo, if one needs to use a strong word like 'offender', then the
> offender
> >> is the one using an internal API. Geode is under no obligation to
> maintain
> >> or "fix" these for any project.
> >>
> >> Is there a Jira, github issue, or pull-request to promote the internal
> >> class to the public space? Is there a feature request to uncouple this
> >> class you want to use in Spring?
> >>
> >> Is Spring the tail wagging the dog for Geode releases?
> >>
> >>
> >> On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <ud...@apache.com> wrote:
> >>
> >>> @Dan,
> >>>
> >>> I will add my -1 to this.
> >>>
> >>> I understand your argument of "let's solve the problem by removing the
> >>> offender".
> >>>
> >>> But in reality who is the offender? Is it the one class that is using
> an
> >>> "internal" api OR is it the implementation itself that is to tightly
> >>> coupled that extending it is impossible?
> >>>
> >>> STDG right now is trying to create a test, to test functionality that
> >>> requires it to inject/mock a Pool. The smallest piece of the code, not
> >>> the WHOLE PoolManager. But the system does not allow for the injection
> >>> of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
> >>> arguments). It casts every generic `Pool` to its implementation. This
> is
> >>> a very limiting factor.
> >>>
> >>> I understand that delaying a release is not optimal, but how much
> effort
> >>> to we believe it to be to clean up the code that so tightly couples
> >>> implementations together.
> >>>
> >>> I think we also must not forget that John, like many of us, is a
> >>> committer and PMC member on Geode. He also happens to be the main
> >>> committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
> >>> should not go out without fixing a limiting feature to the Geode
> >>> project, then he may do so.
> >>>
> >>> I also feel that this is a limiting factor.
> >>>
> >>> The only difference is that I am not the main committer on the Spring
> >>> data projects for Geode. John is merely trying to get the best outcome
> >>> for both projects.
> >>>
> >>> --Udo
> >>>
> >>> On 12/4/19 4:39 PM, Dan Smith wrote:
> >>>>> Quite frankly the reasons STDG (or dependent projects downstream like
> >>> SDG,
> >>>>> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to
> >> point
> >>>>> articulated in the description of GEODE-753.
> >>>>>
> >>>> What bothers me here is not your suggestions in GEODE-1753, but the
> >> fact
> >>>> that you are vetoing a Geode release because STDG is using an internal
> >>>> Geode method and had a problem.
> >>>>
> >>>> How hard is it to remove the use of PoolManagerImpl from STDG? If we
> >> can
> >>>> fix the issue there, that seems better than putting bandaids into the
> >>>> release branch so STDG can continue to use internal APIs.
> >>>>
> >>>> -Dan
> >>>>
> >>>
> >>
> >
> >
> > --
> > -John
> > Spring Data Team
>
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Jacob Barrett <jb...@pivotal.io>.
I think we can tone down the inflammatory statements. It is well established that, like any legacy code base, Geode has issues. One of them is a less than ideal set of APIs for certain tasks. Whatever the issues were in the past with getting APIs adjusted to suit the SDG project should be left in the past and we can work forward on a new strategy.
The term public API is redundant, if its designated API then it is public. Let’s also be clear that "internal API” is not a thing, if it is internal it is not an API. The language semantics of public/private are not what defines and API. As such, relying on internal classes tor work around deficiencies in a API is dangerous and should only be done as a stopgap measure while addressing the API’s deficiency. Java, up until 9, lacked any clear distinction of internals vs API so, like many projects, Geode chose the “internal” package name to denote things that are not to be consume as API. As we go forward with Java 9 modules support these will be enforced by the runtime and compilers.
A JIRA should be opened to address the API deficiency. When the API is enhanced then the internal class usage should be replaced immediately with the API. It is unreasonable to expect an upstream project to maintain internal classes as though they are API or expect them to address deficiencies in the API if they are not communicated. It is also unreasonable for the upstream project to ignore obvious deficiencies in its APIs and should use these issues raised by downstream projects to prioritize improvements. Work needs to be done on both these projects to make improvements.
To resolve the issues raised below let’s get some JIRAs and/or RFCs opened to address the APIs the SDG needs to work. Let’s work to burn down this debt of internal class usage in SDG to avoid issues like this in the future. I am sure we can figure out a short term solution to address the immediate compile issues, whether that’s making a unit test into an integration test, refactoring the internals to not blindly cast, or whatever. We can then work out a strategy to address this the correct way in the develop branch for 1.12.
-Jake
> On Dec 4, 2019, at 6:20 PM, John Blum <jb...@pivotal.io> wrote:
>
> If you must know, there are important test cases in both SBDG and SSDG to
> be able to register (and subsequently unregister) the "mock" Pool with the
> PoolManager, which unfortunately is a consequence of the SDG
> PoolFactoryBean's design being reliant on the PoolManager (to resolve the
> Pool), and to some extent, the PoolFactory API (to create the Pool) in the
> first place. Of course, there is no other way to "resolve" a reference to
> a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
>
> Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
> Apache Geode's public API was properly maintained and evolved to address a
> new use cases. For example (and again), see GEODE-7532
> <https://issues.apache.org/jira/browse/GEODE-7532> [1].
>
> It turns out, there are many, many cases like GEODE-7532
> <https://issues.apache.org/jira/browse/GEODE-7532> [1], with classes and
> methods containing useful functions buried deep down inside Geode
> "internal" packages. The o.a.g.distributed.internal.MemberListener
> interface comes to mind. It is not difficult to see how his interface
> would be useful in both frameworks & tooling (e.g. for management &
> monitoring).
>
> Or, how about the poor resource management/cleanup Apache Geode fails to do
> properly w.r.t. SSL Sockets, that STDG now needs to account for
> <https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139>
> [2]
> when running automated integration tests.
>
> I think there was another example
> <https://markmail.org/message/5juxxnkttzjndidg> [3] recently, which STDG
> must account for <https://markmail.org/message/5juxxnkttzjndidg> [4] as
> well.
>
> Serializer registration/unregistration is yet another area. The laundry
> list is quite long!
>
> The whole notion of Apache Geode's "internal" API is horribly broken,
> especially when the public API often comes up short.
>
> What troubles me is that we see the recommended changes in GEODE-7532 as a
> "bandaid". Really?
>
> It does not matter whether these classes are "internal" or not, nor whether
> they are used (externally) or not, so long as they are used properly. If
> they are "public" there is simply no guarantee they won't be used, and you
> cannot expect "internal" problems to not have external consequences.
>
> SIDE NOTE: Of course, this is further predicated on the fact those
> "internal" classes were designed/implemented correctly in the first place,
> which they also, were not!
>
> I down voted for several reasons:
>
> 1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
> and perhaps, more importantly...
> 2. Because the Pool management in PoolManagerImpl A) refers to the Pool as
> PoolImpl despite taking a reference to Pool, and B) exposes the
> implementation of the usage tracking logic (which is a clear violation of
> "encapsulation" and a series code smell)
> 3. And because the IllegalStateException message is not accurate nor was it
> very informative (e.g. "what Regions").
> 4. Or because 2A by (along with GEODE-7159
> <https://issues.apache.org/jira/browse/GEODE-7159> [5]) will most
> definitely cause problems for us later, especially since these problems
> will be time delayed (invoked during resource cleanup) making them hard to
> pinpoint and very confusing to users.
>
> Also, imagine a scenario where Geode offers different Pool implementations,
> beyond PoolImpl. Why else would Geode provide a PoolFactory interface if
> not to encapsulate creation, configuration and initialization of different
> types of Pools.... part of that *Open/Closed* principle. There is no point
> to have a PoolFactory otherwise since the PoolManager could have simply
> created Pools. Ironically, the PoolFactory is not something that is used
> in this way and therefore became an unnecessary layer of indirection. #sigh
>
> In addition, the recommended changes in GEODE-7531 are not invasive
> what-so-ever, and will not adversely affect Geode 1 way or another.
>
> In closing, anytime the overall code quality of Geode comes into question
> (and there is a lot to question with this codebase), which can, and most
> likely will affect our end-users experience, and it HAS and DOES, you
> better believe and I am going to call this out.
>
> -j
>
>
> [1] https://issues.apache.org/jira/browse/GEODE-7532
> [2]
> https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
> [3] https://markmail.org/message/5juxxnkttzjndidg
> [4] https://markmail.org/message/5juxxnkttzjndidg
> [5] https://issues.apache.org/jira/browse/GEODE-7159
>
> On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton <rh...@pivotal.io> wrote:
>
>> @udo, if one needs to use a strong word like 'offender', then the offender
>> is the one using an internal API. Geode is under no obligation to maintain
>> or "fix" these for any project.
>>
>> Is there a Jira, github issue, or pull-request to promote the internal
>> class to the public space? Is there a feature request to uncouple this
>> class you want to use in Spring?
>>
>> Is Spring the tail wagging the dog for Geode releases?
>>
>>
>> On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <ud...@apache.com> wrote:
>>
>>> @Dan,
>>>
>>> I will add my -1 to this.
>>>
>>> I understand your argument of "let's solve the problem by removing the
>>> offender".
>>>
>>> But in reality who is the offender? Is it the one class that is using an
>>> "internal" api OR is it the implementation itself that is to tightly
>>> coupled that extending it is impossible?
>>>
>>> STDG right now is trying to create a test, to test functionality that
>>> requires it to inject/mock a Pool. The smallest piece of the code, not
>>> the WHOLE PoolManager. But the system does not allow for the injection
>>> of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
>>> arguments). It casts every generic `Pool` to its implementation. This is
>>> a very limiting factor.
>>>
>>> I understand that delaying a release is not optimal, but how much effort
>>> to we believe it to be to clean up the code that so tightly couples
>>> implementations together.
>>>
>>> I think we also must not forget that John, like many of us, is a
>>> committer and PMC member on Geode. He also happens to be the main
>>> committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
>>> should not go out without fixing a limiting feature to the Geode
>>> project, then he may do so.
>>>
>>> I also feel that this is a limiting factor.
>>>
>>> The only difference is that I am not the main committer on the Spring
>>> data projects for Geode. John is merely trying to get the best outcome
>>> for both projects.
>>>
>>> --Udo
>>>
>>> On 12/4/19 4:39 PM, Dan Smith wrote:
>>>>> Quite frankly the reasons STDG (or dependent projects downstream like
>>> SDG,
>>>>> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to
>> point
>>>>> articulated in the description of GEODE-753.
>>>>>
>>>> What bothers me here is not your suggestions in GEODE-1753, but the
>> fact
>>>> that you are vetoing a Geode release because STDG is using an internal
>>>> Geode method and had a problem.
>>>>
>>>> How hard is it to remove the use of PoolManagerImpl from STDG? If we
>> can
>>>> fix the issue there, that seems better than putting bandaids into the
>>>> release branch so STDG can continue to use internal APIs.
>>>>
>>>> -Dan
>>>>
>>>
>>
>
>
> --
> -John
> Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
If you must know, there are important test cases in both SBDG and SSDG to
be able to register (and subsequently unregister) the "mock" Pool with the
PoolManager, which unfortunately is a consequence of the SDG
PoolFactoryBean's design being reliant on the PoolManager (to resolve the
Pool), and to some extent, the PoolFactory API (to create the Pool) in the
first place. Of course, there is no other way to "resolve" a reference to
a Pool from Geode (other than ClientCache.geDefaultPool()), AFAIK.
Unfortunately, STDG (or SDG) would not need to import "internal" APIs if
Apache Geode's public API was properly maintained and evolved to address a
new use cases. For example (and again), see GEODE-7532
<https://issues.apache.org/jira/browse/GEODE-7532> [1].
It turns out, there are many, many cases like GEODE-7532
<https://issues.apache.org/jira/browse/GEODE-7532> [1], with classes and
methods containing useful functions buried deep down inside Geode
"internal" packages. The o.a.g.distributed.internal.MemberListener
interface comes to mind. It is not difficult to see how his interface
would be useful in both frameworks & tooling (e.g. for management &
monitoring).
Or, how about the poor resource management/cleanup Apache Geode fails to do
properly w.r.t. SSL Sockets, that STDG now needs to account for
<https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139>
[2]
when running automated integration tests.
I think there was another example
<https://markmail.org/message/5juxxnkttzjndidg> [3] recently, which STDG
must account for <https://markmail.org/message/5juxxnkttzjndidg> [4] as
well.
Serializer registration/unregistration is yet another area. The laundry
list is quite long!
The whole notion of Apache Geode's "internal" API is horribly broken,
especially when the public API often comes up short.
What troubles me is that we see the recommended changes in GEODE-7532 as a
"bandaid". Really?
It does not matter whether these classes are "internal" or not, nor whether
they are used (externally) or not, so long as they are used properly. If
they are "public" there is simply no guarantee they won't be used, and you
cannot expect "internal" problems to not have external consequences.
SIDE NOTE: Of course, this is further predicated on the fact those
"internal" classes were designed/implemented correctly in the first place,
which they also, were not!
I down voted for several reasons:
1. First, YES, because this blocks SBDG from moving to Apache Geode 1.11,
and perhaps, more importantly...
2. Because the Pool management in PoolManagerImpl A) refers to the Pool as
PoolImpl despite taking a reference to Pool, and B) exposes the
implementation of the usage tracking logic (which is a clear violation of
"encapsulation" and a series code smell)
3. And because the IllegalStateException message is not accurate nor was it
very informative (e.g. "what Regions").
4. Or because 2A by (along with GEODE-7159
<https://issues.apache.org/jira/browse/GEODE-7159> [5]) will most
definitely cause problems for us later, especially since these problems
will be time delayed (invoked during resource cleanup) making them hard to
pinpoint and very confusing to users.
Also, imagine a scenario where Geode offers different Pool implementations,
beyond PoolImpl. Why else would Geode provide a PoolFactory interface if
not to encapsulate creation, configuration and initialization of different
types of Pools.... part of that *Open/Closed* principle. There is no point
to have a PoolFactory otherwise since the PoolManager could have simply
created Pools. Ironically, the PoolFactory is not something that is used
in this way and therefore became an unnecessary layer of indirection. #sigh
In addition, the recommended changes in GEODE-7531 are not invasive
what-so-ever, and will not adversely affect Geode 1 way or another.
In closing, anytime the overall code quality of Geode comes into question
(and there is a lot to question with this codebase), which can, and most
likely will affect our end-users experience, and it HAS and DOES, you
better believe and I am going to call this out.
-j
[1] https://issues.apache.org/jira/browse/GEODE-7532
[2]
https://github.com/spring-projects/spring-test-data-geode/blob/master/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/integration/IntegrationTestsSupport.java#L119-L139
[3] https://markmail.org/message/5juxxnkttzjndidg
[4] https://markmail.org/message/5juxxnkttzjndidg
[5] https://issues.apache.org/jira/browse/GEODE-7159
On Wed, Dec 4, 2019 at 6:12 PM Robert Houghton <rh...@pivotal.io> wrote:
> @udo, if one needs to use a strong word like 'offender', then the offender
> is the one using an internal API. Geode is under no obligation to maintain
> or "fix" these for any project.
>
> Is there a Jira, github issue, or pull-request to promote the internal
> class to the public space? Is there a feature request to uncouple this
> class you want to use in Spring?
>
> Is Spring the tail wagging the dog for Geode releases?
>
>
> On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <ud...@apache.com> wrote:
>
> > @Dan,
> >
> > I will add my -1 to this.
> >
> > I understand your argument of "let's solve the problem by removing the
> > offender".
> >
> > But in reality who is the offender? Is it the one class that is using an
> > "internal" api OR is it the implementation itself that is to tightly
> > coupled that extending it is impossible?
> >
> > STDG right now is trying to create a test, to test functionality that
> > requires it to inject/mock a Pool. The smallest piece of the code, not
> > the WHOLE PoolManager. But the system does not allow for the injection
> > of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
> > arguments). It casts every generic `Pool` to its implementation. This is
> > a very limiting factor.
> >
> > I understand that delaying a release is not optimal, but how much effort
> > to we believe it to be to clean up the code that so tightly couples
> > implementations together.
> >
> > I think we also must not forget that John, like many of us, is a
> > committer and PMC member on Geode. He also happens to be the main
> > committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
> > should not go out without fixing a limiting feature to the Geode
> > project, then he may do so.
> >
> > I also feel that this is a limiting factor.
> >
> > The only difference is that I am not the main committer on the Spring
> > data projects for Geode. John is merely trying to get the best outcome
> > for both projects.
> >
> > --Udo
> >
> > On 12/4/19 4:39 PM, Dan Smith wrote:
> > >> Quite frankly the reasons STDG (or dependent projects downstream like
> > SDG,
> > >> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to
> point
> > >> articulated in the description of GEODE-753.
> > >>
> > > What bothers me here is not your suggestions in GEODE-1753, but the
> fact
> > > that you are vetoing a Geode release because STDG is using an internal
> > > Geode method and had a problem.
> > >
> > > How hard is it to remove the use of PoolManagerImpl from STDG? If we
> can
> > > fix the issue there, that seems better than putting bandaids into the
> > > release branch so STDG can continue to use internal APIs.
> > >
> > > -Dan
> > >
> >
>
--
-John
Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Robert Houghton <rh...@pivotal.io>.
@udo, if one needs to use a strong word like 'offender', then the offender
is the one using an internal API. Geode is under no obligation to maintain
or "fix" these for any project.
Is there a Jira, github issue, or pull-request to promote the internal
class to the public space? Is there a feature request to uncouple this
class you want to use in Spring?
Is Spring the tail wagging the dog for Geode releases?
On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <ud...@apache.com> wrote:
> @Dan,
>
> I will add my -1 to this.
>
> I understand your argument of "let's solve the problem by removing the
> offender".
>
> But in reality who is the offender? Is it the one class that is using an
> "internal" api OR is it the implementation itself that is to tightly
> coupled that extending it is impossible?
>
> STDG right now is trying to create a test, to test functionality that
> requires it to inject/mock a Pool. The smallest piece of the code, not
> the WHOLE PoolManager. But the system does not allow for the injection
> of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
> arguments). It casts every generic `Pool` to its implementation. This is
> a very limiting factor.
>
> I understand that delaying a release is not optimal, but how much effort
> to we believe it to be to clean up the code that so tightly couples
> implementations together.
>
> I think we also must not forget that John, like many of us, is a
> committer and PMC member on Geode. He also happens to be the main
> committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
> should not go out without fixing a limiting feature to the Geode
> project, then he may do so.
>
> I also feel that this is a limiting factor.
>
> The only difference is that I am not the main committer on the Spring
> data projects for Geode. John is merely trying to get the best outcome
> for both projects.
>
> --Udo
>
> On 12/4/19 4:39 PM, Dan Smith wrote:
> >> Quite frankly the reasons STDG (or dependent projects downstream like
> SDG,
> >> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
> >> articulated in the description of GEODE-753.
> >>
> > What bothers me here is not your suggestions in GEODE-1753, but the fact
> > that you are vetoing a Geode release because STDG is using an internal
> > Geode method and had a problem.
> >
> > How hard is it to remove the use of PoolManagerImpl from STDG? If we can
> > fix the issue there, that seems better than putting bandaids into the
> > release branch so STDG can continue to use internal APIs.
> >
> > -Dan
> >
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Udo Kohlmeyer <ud...@apache.com>.
@Dan,
I will add my -1 to this.
I understand your argument of "let's solve the problem by removing the
offender".
But in reality who is the offender? Is it the one class that is using an
"internal" api OR is it the implementation itself that is to tightly
coupled that extending it is impossible?
STDG right now is trying to create a test, to test functionality that
requires it to inject/mock a Pool. The smallest piece of the code, not
the WHOLE PoolManager. But the system does not allow for the injection
of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as
arguments). It casts every generic `Pool` to its implementation. This is
a very limiting factor.
I understand that delaying a release is not optimal, but how much effort
to we believe it to be to clean up the code that so tightly couples
implementations together.
I think we also must not forget that John, like many of us, is a
committer and PMC member on Geode. He also happens to be the main
committer on SDG, SBDG, SSDG, STDG. But if he feels that a release
should not go out without fixing a limiting feature to the Geode
project, then he may do so.
I also feel that this is a limiting factor.
The only difference is that I am not the main committer on the Spring
data projects for Geode. John is merely trying to get the best outcome
for both projects.
--Udo
On 12/4/19 4:39 PM, Dan Smith wrote:
>> Quite frankly the reasons STDG (or dependent projects downstream like SDG,
>> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
>> articulated in the description of GEODE-753.
>>
> What bothers me here is not your suggestions in GEODE-1753, but the fact
> that you are vetoing a Geode release because STDG is using an internal
> Geode method and had a problem.
>
> How hard is it to remove the use of PoolManagerImpl from STDG? If we can
> fix the issue there, that seems better than putting bandaids into the
> release branch so STDG can continue to use internal APIs.
>
> -Dan
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Dan Smith <ds...@pivotal.io>.
>
> Quite frankly the reasons STDG (or dependent projects downstream like SDG,
> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
> articulated in the description of GEODE-753.
>
What bothers me here is not your suggestions in GEODE-1753, but the fact
that you are vetoing a Geode release because STDG is using an internal
Geode method and had a problem.
How hard is it to remove the use of PoolManagerImpl from STDG? If we can
fix the issue there, that seems better than putting bandaids into the
release branch so STDG can continue to use internal APIs.
-Dan
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
See comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282>
[1]
on ticket, GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531>
[2].
Quite frankly the reasons STDG (or dependent projects downstream like SDG,
SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point
articulated in the description of GEODE-753.
[1]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16988282
[2] https://issues.apache.org/jira/browse/GEODE-7531
On Wed, Dec 4, 2019 at 4:06 PM Dan Smith <ds...@pivotal.io> wrote:
> On Wed, Dec 4, 2019 at 2:11 PM John Blum <jb...@pivotal.io> wrote:
>
> > This is not a test failure in SDG. SDG builds fine with Apache Geode
> 1.11
> > (and all tests pass), as I indicated above in my origin +0 vote.
> >
> > This is a definitive problem for SBDG when using STDG to mock Apache
> Geode
> > resources/objects, which is caused by GEODE-7531.
> >
>
> Hmm, looks like STDG is also using an internal API to inject a mock into
> the PoolManager singleton:
>
> https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750
>
> Maybe it would be better to fix that? I don't think injecting anything into
> Geode singletons is a good approach - it will likely lead to mysterious
> errors in future tests. And using internal APIs tends to result in breakage
> while upgrading, as evidenced here.
>
> A more complete fix to Geode might be deprecate the static PoolManager
> entirely and move the pool management functionality to ClientCache. That
> might make it easier for you to mock the whole system? In the short term
> perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
> a mock injected into it, without using internal APIs?
>
> -Dan
>
--
-John
Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Dan Smith <ds...@pivotal.io>.
On Wed, Dec 4, 2019 at 2:11 PM John Blum <jb...@pivotal.io> wrote:
> This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
> (and all tests pass), as I indicated above in my origin +0 vote.
>
> This is a definitive problem for SBDG when using STDG to mock Apache Geode
> resources/objects, which is caused by GEODE-7531.
>
Hmm, looks like STDG is also using an internal API to inject a mock into
the PoolManager singleton:
https://github.com/spring-projects/spring-test-data-geode/blob/9a091376528cd79c978bc5b3019d30256fcf3fd5/spring-data-geode-test/src/main/java/org/springframework/data/gemfire/tests/mock/GemFireMockObjectsSupport.java#L1750
Maybe it would be better to fix that? I don't think injecting anything into
Geode singletons is a good approach - it will likely lead to mysterious
errors in future tests. And using internal APIs tends to result in breakage
while upgrading, as evidenced here.
A more complete fix to Geode might be deprecate the static PoolManager
entirely and move the pool management functionality to ClientCache. That
might make it easier for you to mock the whole system? In the short term
perhaps SDG, STDG, etc. can wrap the PoolManager in something that can have
a mock injected into it, without using internal APIs?
-Dan
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11
(and all tests pass), as I indicated above in my origin +0 vote.
This is a definitive problem for SBDG when using STDG to mock Apache Geode
resources/objects, which is caused by GEODE-7531.
Either way, the design/code changes made in GEODE-6759 were poor and should
be fixed regardless which GEODE-7531 describes.
-j
On Wed, Dec 4, 2019 at 2:04 PM Dan Smith <ds...@pivotal.io> wrote:
> On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
>
> > I am changing my vote to -1!
> >
> > I have filed GEODE-7531 <
> https://issues.apache.org/jira/browse/GEODE-7531>
> > [1],
> > which is a serious blocking issue for all things *Spring* for Apache
> > Geode. This issue alone is currently preventing me from upgrading
> *Spring
> > Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> > SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> > Neumann/2.3, which is currently already pulling in Apache Geode 1.10,
> soon
> > to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
> >
>
>
> I commented on the above JIRA. While we definitely don't want to break
> spring data geode, it looks like maybe the issue is just with one unit test
> in Spring Data Geode using an internal geode API to inject something into a
> singleton? If that's the case, I think it would be better to fix that one
> test in SDG.
>
> -Dan
>
--
-John
Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Dan Smith <ds...@pivotal.io>.
On Wed, Dec 4, 2019 at 11:16 AM John Blum <jb...@pivotal.io> wrote:
> I am changing my vote to -1!
>
> I have filed GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531>
> [1],
> which is a serious blocking issue for all things *Spring* for Apache
> Geode. This issue alone is currently preventing me from upgrading *Spring
> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>
I commented on the above JIRA. While we definitely don't want to break
spring data geode, it looks like maybe the issue is just with one unit test
in Spring Data Geode using an internal geode API to inject something into a
singleton? If that's the case, I think it would be better to fix that one
test in SDG.
-Dan
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Mark Hanson <mh...@pivotal.io>.
Just an update…
1.11.0.RC3 is not going out. We are in a holding pattern on RC4 due to the issue that Lynn mentioned and other issues found.
This is another strike against that RC3 release.
If the contributors deem the fix necessary ( I assume they would ), we will put in a fix for that as well.
I will provide the full list of outstanding issues shortly.
Thanks,
Mark
> On Dec 4, 2019, at 11:16 AM, John Blum <jb...@pivotal.io> wrote:
>
> I am changing my vote to -1!
>
> I have filed GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531> [1],
> which is a serious blocking issue for all things *Spring* for Apache
> Geode. This issue alone is currently preventing me from upgrading *Spring
> Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
> SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
> Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
> to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
>
> If you need further explanation, you don't need to look any further than
> the description as well as my comment
> <https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096>
> [2].
>
> -j
>
> [1] https://issues.apache.org/jira/browse/GEODE-7531
> [2]
> https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096
>
>
> On Wed, Dec 4, 2019 at 9:24 AM John Blum <jb...@pivotal.io> wrote:
>
>> Indeed, both dependencies (geode-logging & geode-serialization) are
>> listed as runtime dependencies.
>>
>> *> Is SDG creating its dependencies manually?*
>>
>> I am not quite following your thinking on this question. Of course SDG
>> uses transitive dependencies. SDG must declare direct dependencies on
>> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
>> features API to implement the functionality provided by SDG.
>>
>> Anyway, it because Apache Geode's public API is broken/incomplete
>> (especially from a framework/tooling perspective, but even an application
>> perspective in many cases) that SDG must rely on certain (non-protected)
>> "internal" APIs. It turns out that those "internal" classes have hard
>> (i.e. compile-time) dependencies on geode-logging & geode-serialization
>> to even build a project (application, framework or otherwise) using those
>> classes with Apache Geode.
>>
>> I am currently exploring whether I can alter the use of the "internal"
>> class(es) to avoid forcing a compile-time dependency.
>>
>> -j
>>
>>
>> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett <jb...@pivotal.io> wrote:
>>
>>>
>>>
>>>> On Dec 1, 2019, at 2:40 PM, John Blum <jb...@pivotal.io> wrote:
>>>>
>>>> After some modifications to Spring Data for Apache Geode (Spring Data
>>>> Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>>>>
>>>> While I support the modularization effort, I would make it very clear
>>> (in
>>>> documentation) now that both geode-logging and geode-serialization are
>>>> required on the application classpath when using Apache Geode.
>>>>
>>>> Technically, I am not entirely certain about geode-serialization (yet),
>>> but
>>>> geode-logging is strictly required to use Apache Geode. I need to run
>>> some
>>>> more tests.
>>>
>>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>>> creating its dependencies manually or using the transitive dependencies
>>> from the Geode POMs?
>>>
>>> -Jake
>>>
>>>
>>>
>>>
>>
>> --
>> -John
>> john.blum10101 (skype)
>>
>
>
> --
> -John
> Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
I am changing my vote to -1!
I have filed GEODE-7531 <https://issues.apache.org/jira/browse/GEODE-7531> [1],
which is a serious blocking issue for all things *Spring* for Apache
Geode. This issue alone is currently preventing me from upgrading *Spring
Boot for Apache Geode* (SBDG) to Apache Geode 1.10, which I plan to do in
SBDG 1.3, which is based on *Spring Data for Apache Geode* (SDG)
Neumann/2.3, which is currently already pulling in Apache Geode 1.10, soon
to be upgraded to 1.11 once this issue is resolved and 1.11 is available.
If you need further explanation, you don't need to look any further than
the description as well as my comment
<https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096>
[2].
-j
[1] https://issues.apache.org/jira/browse/GEODE-7531
[2]
https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16988096
On Wed, Dec 4, 2019 at 9:24 AM John Blum <jb...@pivotal.io> wrote:
> Indeed, both dependencies (geode-logging & geode-serialization) are
> listed as runtime dependencies.
>
> *> Is SDG creating its dependencies manually?*
>
> I am not quite following your thinking on this question. Of course SDG
> uses transitive dependencies. SDG must declare direct dependencies on
> geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
> features API to implement the functionality provided by SDG.
>
> Anyway, it because Apache Geode's public API is broken/incomplete
> (especially from a framework/tooling perspective, but even an application
> perspective in many cases) that SDG must rely on certain (non-protected)
> "internal" APIs. It turns out that those "internal" classes have hard
> (i.e. compile-time) dependencies on geode-logging & geode-serialization
> to even build a project (application, framework or otherwise) using those
> classes with Apache Geode.
>
> I am currently exploring whether I can alter the use of the "internal"
> class(es) to avoid forcing a compile-time dependency.
>
> -j
>
>
> On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>>
>>
>> > On Dec 1, 2019, at 2:40 PM, John Blum <jb...@pivotal.io> wrote:
>> >
>> > After some modifications to Spring Data for Apache Geode (Spring Data
>> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>> >
>> > While I support the modularization effort, I would make it very clear
>> (in
>> > documentation) now that both geode-logging and geode-serialization are
>> > required on the application classpath when using Apache Geode.
>> >
>> > Technically, I am not entirely certain about geode-serialization (yet),
>> but
>> > geode-logging is strictly required to use Apache Geode. I need to run
>> some
>> > more tests.
>>
>> Both are properly listed as runtime scope in the geode-core POM. Is SDG
>> creating its dependencies manually or using the transitive dependencies
>> from the Geode POMs?
>>
>> -Jake
>>
>>
>>
>>
>
> --
> -John
> john.blum10101 (skype)
>
--
-John
Spring Data Team
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
Indeed, both dependencies (geode-logging & geode-serialization) are listed
as runtime dependencies.
*> Is SDG creating its dependencies manually?*
I am not quite following your thinking on this question. Of course SDG
uses transitive dependencies. SDG must declare direct dependencies on
geode-core, geode-cq, geode-lucene and geode-wan., as it is using those
features API to implement the functionality provided by SDG.
Anyway, it because Apache Geode's public API is broken/incomplete
(especially from a framework/tooling perspective, but even an application
perspective in many cases) that SDG must rely on certain (non-protected)
"internal" APIs. It turns out that those "internal" classes have hard
(i.e. compile-time) dependencies on geode-logging & geode-serialization to
even build a project (application, framework or otherwise) using those
classes with Apache Geode.
I am currently exploring whether I can alter the use of the "internal"
class(es) to avoid forcing a compile-time dependency.
-j
On Mon, Dec 2, 2019 at 12:42 PM Jacob Barrett <jb...@pivotal.io> wrote:
>
>
> > On Dec 1, 2019, at 2:40 PM, John Blum <jb...@pivotal.io> wrote:
> >
> > After some modifications to Spring Data for Apache Geode (Spring Data
> > Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
> >
> > While I support the modularization effort, I would make it very clear (in
> > documentation) now that both geode-logging and geode-serialization are
> > required on the application classpath when using Apache Geode.
> >
> > Technically, I am not entirely certain about geode-serialization (yet),
> but
> > geode-logging is strictly required to use Apache Geode. I need to run
> some
> > more tests.
>
> Both are properly listed as runtime scope in the geode-core POM. Is SDG
> creating its dependencies manually or using the transitive dependencies
> from the Geode POMs?
>
> -Jake
>
>
>
>
--
-John
john.blum10101 (skype)
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Dec 1, 2019, at 2:40 PM, John Blum <jb...@pivotal.io> wrote:
>
> After some modifications to Spring Data for Apache Geode (Spring Data
> Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
>
> While I support the modularization effort, I would make it very clear (in
> documentation) now that both geode-logging and geode-serialization are
> required on the application classpath when using Apache Geode.
>
> Technically, I am not entirely certain about geode-serialization (yet), but
> geode-logging is strictly required to use Apache Geode. I need to run some
> more tests.
Both are properly listed as runtime scope in the geode-core POM. Is SDG creating its dependencies manually or using the transitive dependencies from the Geode POMs?
-Jake
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by John Blum <jb...@pivotal.io>.
+0
After some modifications to Spring Data for Apache Geode (Spring Data
Geode; SDG), I was finally able to build SDG with Apache Geode 1.11.
While I support the modularization effort, I would make it very clear (in
documentation) now that both geode-logging and geode-serialization are
required on the application classpath when using Apache Geode.
Technically, I am not entirely certain about geode-serialization (yet), but
geode-logging is strictly required to use Apache Geode. I need to run some
more tests.
-j
On Tue, Nov 26, 2019 at 11:46 AM Blake Bender <bb...@pivotal.io> wrote:
> -1 from native client as well, sorry. RC3 mistakenly picked up an
> unnecessary commit, and left out the crash fix I needed. If you revert
> commit 5d012199055a9a7657563727f6e26a406b287fc3 and
> cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
> segfault in log message.", native client should be good to go.
>
> Thanks,
>
> Blake
>
>
>
> On Tue, Nov 26, 2019 at 11:35 AM Lynn Hughes-Godfrey <
> lhughesgodfrey@pivotal.io> wrote:
>
> > -1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
> > all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
> > https://issues.apache.org/jira/browse/GEODE-5307
> >
> > On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson <mh...@pivotal.io> wrote:
> >
> > > Hello Geode Dev Community,
> > >
> > > This is a release candidate for Apache Geode version 1.11.0.RC3.
> > > Thanks to all the community members for their contributions to this
> > > release!
> > >
> > > Please do a review and give your feedback, including the checks you
> > > performed.
> > >
> > > Voting deadline:
> > > 11AM PST Monday December 2 2019.
> > >
> > > Please note that we are voting upon the source tag:
> > > rel/v1.11.0.RC3
> > >
> > > Release notes:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> > >
> > > Source and binary distributions:
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
> > >
> > > Maven staging repo:
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > >
> > > GitHub:
> > > https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> > > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
> > >
> > > Pipelines:
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> > >
> > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > https://github.com/apache/geode/blob/develop/KEYS
> > >
> > > Command to run geode-examples:
> > > ./gradlew -PgeodeReleaseUrl=
> > > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> > > -PgeodeRepositoryUrl=
> > > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > > build runAll
> > >
> > > Regards
> > > Mark Hanson
> >
>
--
-John
john.blum10101 (skype)
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Blake Bender <bb...@pivotal.io>.
-1 from native client as well, sorry. RC3 mistakenly picked up an
unnecessary commit, and left out the crash fix I needed. If you revert
commit 5d012199055a9a7657563727f6e26a406b287fc3 and
cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
segfault in log message.", native client should be good to go.
Thanks,
Blake
On Tue, Nov 26, 2019 at 11:35 AM Lynn Hughes-Godfrey <
lhughesgodfrey@pivotal.io> wrote:
> -1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
> all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
> https://issues.apache.org/jira/browse/GEODE-5307
>
> On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson <mh...@pivotal.io> wrote:
>
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.11.0.RC3.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 11AM PST Monday December 2 2019.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.11.0.RC3
> >
> > Release notes:
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1063
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
> >
> > Pipelines:
> >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > build runAll
> >
> > Regards
> > Mark Hanson
>
Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.
Posted by Lynn Hughes-Godfrey <lh...@pivotal.io>.
-1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
https://issues.apache.org/jira/browse/GEODE-5307
On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson <mh...@pivotal.io> wrote:
> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.11.0.RC3.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 11AM PST Monday December 2 2019.
>
> Please note that we are voting upon the source tag:
> rel/v1.11.0.RC3
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1063
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1063
> build runAll
>
> Regards
> Mark Hanson