Re: Dependency review for release 1.9.0

Well, that just requires that you appropriately declare dependencies with the "optionality" and "scope" (e.g. "compile", "test", "provided", etc). Additionally, Geode modules could selectively pull in the required deps as needed. For example, `geode-lucene` would only pull in the Apache Lucene de

Re: Dependency review for release 1.9.0

vers launched > through gfsh start server unless we provide a way to configure which geode > modules are present on the server's classpath. > > -Dan > > On Thu, Feb 28, 2019 at 10:03 AM John Blum wrote: > > > Well, that just requires that you appropriately declare

Re: Dependency review for release 1.9.0

4-L61 [3] https://github.com/jxblum/spring-session-data-gemfire-serialization-example/blob/master/native-gemfire-server/src/main/java/example/app/gemfire/server/NativeGemFireServerApplication.java On Thu, Feb 28, 2019 at 10:35 AM John Blum wrote: > Dan- > > 2 things: > > 1) Users and

Re: Dependency review for release 1.9.0

y/Java/Extensions /Library/Java/Extensions /Network/Library/Java/Extensions /System/Library/Java/Extensions /usr/lib/java . System Properties: PID = 16326 awt.toolkit = sun.lwawt.macosx.LWCToolkit ... On Thu, Feb 28, 2019 at 10:52 AM John Blum wrote: > As an example of #

Re: [DISCUSS] Moving redis to a separate module

Definitely a reasonable change. Perhaps, for consistency sake, the same should be applied to Geode's Memcached support? (in another PR). On Tue, Mar 12, 2019 at 4:23 PM Dan Smith wrote: > I created a PR to move our redis support to a separate module. Let me know > what you think: > > https://g

Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime

If users will be explicitly declaring such dependencies in their applications, then I might also suggest declaring/generating a Maven section in the POM to ensure that the user is getting and using the right version of these dependencies, especially when they don't care about the version (i.e. the

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.M4 Available!

Greetings Apache Geode community and Spring users- I am pleased to bring you the *Spring Boot for Apache Geode* (SBDG) 1.0.0.M4 release. You can read the official announcement on the Spring Blog [1] to find out more details. Next up will be SBDG 1.0.0.RC1 followed shortly by a final 1.0.0.GA as w

Re: [Discuss] Removal of Thread Local Connection Pooling

Well articulated and a wise decision; Jake. +1 On Fri, Apr 5, 2019 at 8:24 AM Anthony Baker wrote: > One question: if I’m using thread-local connections ho does that affect > pool sizing? Are thread-local connections included in the overall pool > size or accounted for separately? > > We may w

Re: How to publish client stats on server

Or alternatively, when using Spring, you can just use @EnableStatistics [1]. [1] https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/config/annotation/EnableStatistics.html On Tue, Apr 16, 2019 at 10:44 AM Darrel Schneider wrote: > setPoolStatisticInterval

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RC1 Released!

I am pleased to announce the release of *Spring Boot for Apache Geode* (SBDG) 1.0.0.RC1. You can read more details in the official release announcement on the spring.io/blog [1]. I have tentatively scheduled the final GA release of SBDG 1.0 on Monday, April 29th, 2019. Any feedback between now a

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RC2 Available!

I am pleased to announce the release of *Spring Boot for Apache Geode* (SBDG) 1.0.0.RC2. You can read more details in the official release announcement on the spring.io/blog [1]. Given feedback from the Boot team, I decided to postpone the 1.0 GA and push out 1 more release candidate. The final

[ANNOUNCE] Spring Boot for Apache Geode 1.0.0.RELEASE Available!

It is my pleasure to announce the first GA release of Spring Boot for Apache Geode (SBDG) 1.0.0.RELEASE. See the official release announcement on spring.io for more details: https://spring.io/blog/2019/05/07/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-release-available Feedback appreciate

Spring Boot for Apache Geode 1.1.0.M1 Released!

I am pleased to announce the release of *Spring Boot for Apache Geode* (SBDG) 1.1.0.M1. See the official release announcement here: https://spring.io/blog/2019/05/07/spring-boot-for-apache-geode-pivotal-gemfire-1-1-0-m1-released The 1.1 Milestone 1 (M1) release primarily rebases SBDG on the lates

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

Of equal importance to uni-directional dependencies in a "modular" design is, classes in package A should not refer directly to classes in package B when A depends on B, or alternately, when module A depends on module B. All interactions are only ever through interfaces and all implementations are

[RELEASE] Spring for Apache Geode Release & Feature Update

Greetings Apache Geode community- I wanted to take this opportunity and let you all know about the recent developments in the *Spring* ecosystem as it relates to Apache Geode for all you *Spring* users out there. ~~ 1. *Spring Data for Apache Geode* (SDG) Lovelace-SR9 (2.1.9.RELEASE) a

Re: [DISCUSS] Time to cut Geode 1.10.0?

A couple of clarifications: 1. First, and most importantly, Pivotal GemFire, specifically (Apache Geode was never officially on *Spring Initializer*, actually) was removed from *Spring Initializer* because *Spring Boot* *1.5.x* has finally reached *End of Life*.Pivotal GemFire existed as an

Re: Another change for 1.10.0 release

+1 for Dan's changes. On Thu, Aug 8, 2019 at 10:28 AM Owen Nichols wrote: > Hi Dan, thank you for bringing your concern. > > Our “critical fixes” rule allows critical fixes to be brought to the > release branch by proposal on the dev list [as you have just done]. If > there is consensus from th

Re: Fix for NPE during forceDisconnect candidate for 1.10.0

+1 for Kirk's changes in 1.10. This will be critical for SD Neuman and SBDG 1.3. On Thu, Aug 8, 2019 at 10:57 AM Owen Nichols wrote: > Hi Kirk and Mark, thank you for bringing your concern. > > Our “critical fixes” rule allows critical fixes to be brought to the > release branch by proposal on

Re: Fix for ClassCastException when using Logback for 1.10.0

+1 On Thu, Aug 8, 2019 at 11:31 AM Juan José Ramos wrote: > +1 > > On Thu, Aug 8, 2019 at 7:26 PM Mark Hanson wrote: > > > +1 > > > > I think it is valuable to make life easier for Spring Boot users. > > > > Thanks, > > Mark > > > > > On Aug 8, 2019, at 11:24 AM, Kirk Lund wrote: > > > > > > T

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

For clarification... 1. SBDG 1.1 is the "*current*" development line (on master [1]); SBDG 1.2 is *not* yet in

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

at that time (e.g. 1.10, maybe 1.11) and continue to be upgraded until 2.3 reaches RC status. Cheers, John On Tue, Aug 13, 2019 at 1:45 PM John Blum wrote: > For clarification... > > 1. SBDG 1.1 is the "*current*" development line (on > <https://github.com/spring-

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

Sorry, corrections below... On Tue, Aug 13, 2019 at 1:54 PM John Blum wrote: > Stated slightly a different way... > > If *SBDG 1.2 *were to be (re)based on *Apache Geode 1.10* directly, then > it would *defy* the dependency on Apache Geode pulled in by SDG Moore/2.2 > (which is

Re: [DISCUSS] Geode dependency update process (review by 8/28/2019)

+1 to Nick's proposal! While you cannot always guarantee that a dependency for whatever version, whether a new major, an updated minor or simply a patch release won't introduce problems (regressions, performance issues, or worse, CVEs), it is extremely important to keep dependencies up-to-date, pr

Re: Proposal to Include GEODE-7079 in 1.10.0

+1 On Thu, Aug 15, 2019 at 5:30 AM Ju@N wrote: > Hello team, > > I'd like to propose including the *fix [1]* for *GEODE-7079 [2]* in release > 1.10.0. > Long story short: a *NullPointerException* can be continuously thrown > and flood the member's logs if a serial event processor (either > *asyn

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

After talking with *Alexander* this morning (and taking *Mike's* concerns into consideration), and to not adversely affect users/customers today, I think... 1). AEQ's can (should) have a configuration setting to "manually" start the queue's background processor (i.e. Thread) to begin processing (e

Re: [DISCUSS] Controlling event dispatch to AsyncEventListener (review by Aug 22)

FTR, I am not opposed to *Naba's* idea either. +1 I kind of like the idea of having a global, cache-wide call that can coordinate the background initialization/processing of all other Geode objects that have lifecycle processes starting in the background (e.g. Gateways, AEQs, etc). On Tue, A

Re: [DISCUSS] Release Geode 1.9.1 with logging improvements

; > > -Owen > > > > > >> On Aug 18, 2019, at 7:52 AM, Anthony Baker wrote: > >> > >> Yep. Get a release manager, identify and cherry pick all the changes, > then do the release. > >> > >> Anthony > >> > >>> On Aug 1

Re: [VOTE] Apache Geode 1.9.1 RC1

+1 On Wed, Aug 28, 2019 at 2:51 PM Dan Smith wrote: > I missed this vote email as well - if we reopen the vote I'll cast one. I > don't really have much context on why we want a 1.9.1 but I'm happy to > double check the bits. > > One comment on this RC - I noticed that we bumped the ordinal in >

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

+1 On Thu, Aug 29, 2019 at 9:41 AM Kirk Lund wrote: > +1 (just in case my vote counts) > > On Thu, Aug 29, 2019 at 9:02 AM Kirk Lund wrote: > > > Hello Geode dev community, > > > > This is a release candidate for Apache Geode, version 1.9.1.RC1. > > Thanks to all the community members for their

Re: [VOTE] Apache Geode 1.9.1 RC1

FWIW, I don't think 1.9.1 clients (or any combination of patch versions) should be incompatible with servers 1.9.patch-1 (e.g. 1.9.0). IMO, that would be very bad! major.minor client/servers, regardless of patch versions, should remain interoperable. On Thu, Aug 29, 2019 at 11:41 AM Owen Nichols

Re: [VOTE] Apache Geode 1.9.1 RC1 (new vote)

Final SD[G] Moore-RELEASE/2.2 GA is (tentatively) scheduled for Thurs, Sept 19th. Even still, any SD[G] Moore service release post GA (e.g. 2.2.1, 2.2.2, ..., 2.2.N) can pick up any patch release of Apache Geode 1.9.x (e.g. 1.9.1, 1.9.2, ..., 1.9.N). Additionally, SBDG 1.2 cannot go GA before *Sp

Re: [VOTE] Apache Geode 1.9.1 RC2

+1 On Thu, Aug 29, 2019 at 5:40 PM Udo Kohlmeyer wrote: > +1 > > On 8/29/19 5:02 PM, Owen Nichols wrote: > > Hello Geode dev community, > > > > This is a release candidate for Apache Geode, version 1.9.1.RC2. > > Thanks to all the community members for their contributions to this > release! > >

Re: [VOTE] Apache Geode 1.9.1.RC3

+1 Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3). However, can we seriously reconsider logging the follow message at ERROR? Ugh! ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the consol

Re: [VOTE] Apache Geode 1.9.1.RC3

. -John On Tue, Sep 3, 2019 at 10:40 AM John Blum wrote: > +1 > > Ran SDG build against Apache Geode 1.9.1 build snapshots (for RC3). > > However, can we seriously reconsider logging the follow message at ERROR? > Ugh! > > ERROR StatusLogger Log4j2 could not find a loggi

Re: [ANNOUNCE] Apache Geode 1.9.1

Congrats Geode Community! On Fri, Sep 6, 2019 at 11:04 AM Owen Nichols wrote: > The Apache Geode community is pleased to announce the availability of > Apache Geode 1.9.1. > > Apache Geode is a data management platform that provides a database-like > consistency model, reliable transaction proce

Re: [Proposal] Make gfsh "stop server" command synchronous

`stop server` is synchronous (with an option to break out of the wait using CTRL^C) AFAIR. Way deep down inside, it simply relies on GemFireCache.close() to return (in-process). As Darrel mentioned, there is not "true" signal the the server was successfully stopped. -j On Tue, Sep 10, 2019 at

Re: [Proposal] Make gfsh "stop server" command synchronous

I have a change that seems viable that waits for the pid file to > disappear from the subdirectory of the server. I am not a fan. I would > prefer to wait for the pid to disappear, but that doesn’t seem like it will > be cross-platform friendly. > > Thanks, > Mark > &

Re: [Proposal] Make gfsh "stop server" command synchronous

tion. > Maybe we should consider that nearly all gfsh commands are not blocking, > and rather, have a way to determine which ones are still waiting for > completion? > > -- > Mike Stolz > Principal Engineer, Pivotal Cloud Cache > Mobile: +1-631-835-4771 > > >

Re: [Proposal] Make gfsh "stop server" command synchronous

+1 to Bruce's comments as well. This is exactly the kind of thing I needed to do (handle) inside of the *Spring Test for Apache Geode* (STDG) project from a framework perspective, to ensure that other projects relying on STDG (e.g. SBDG, SSDG) for their integration testing purposes (e.g. client/se

Re: [DISCUSS] - Cutting of release 1.9.2

Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is tentatively scheduled for Monday, Sept. 30th. On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund wrote: > Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG 2.2.0? > > On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer

Re: [DISCUSS] - Cutting of release 1.9.2

pache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix ). On Fri, Sep 20, 2019 at 1:09 PM John Blum wrote: > Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which is > tentatively scheduled for Monday, Sept. 30th. > > On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund w

Re: [DISCUSS] - Cutting of release 1.9.2

+1 for releasing Apache Geode 1.9.2 and including the fix for GEDOE-7121. On Fri, Sep 20, 2019 at 1:11 PM Kirk Lund wrote: > +1 for creating 1.9.x with the fix for GEODE-7121 > > > On Fri, Sep 20, 2019 at 1:09 PM John Blum wrote: > > > Hi Kirk - SDG 2.3/Neuman, which

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Bundling "all" dependencies in a WAR file is a rather subjective topic since, typically, in practice developers did not bundle things like JDBC drivers in a WAR file for their Web app. Common practice was to put "shared" libs in the Servlet Containers global libs directory (using the Common ClassL

Re: [DISCUSS] GEODE-7241 - make Jar not War?

Actually, to clarify 2 points. 1. Technically, it is a bit more involved than simply just validating the "format". For instance, the web.xml file must be valid and well-formed. 2. There was a reason why the geode-core and other Apache Geode libs were not bundled in WEB-INF/lib of the WAR files, s

Re: [DISCUSS] GEODE-7241 - make Jar not War?

It occurred to me after *Charlie* shared the link to installing *Pulse* in a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly describe how to handle the Geode dependencies (e.g. geode-core). Again, this is not bundled as part of the Geode WAR files. -1 to publishing a GWAR

Re: [DISCUSS] GEODE-7241 - make Jar not War?

@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar. I never heard of them until now. Gotta love the 80s Rock/Heavy Metal Era. On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett wrote: > Udo, > > I didn’t say we shouldn’t fix it for the future. I said I don’t believe it > warrants a backpo

Re: Spring Boot with Geode 1.10

There is no version of Spring Boot (SBDG) currently built on Apache Geode 1.10 at the moment. In general, you should understand 2 things. 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent on is indirectly (transitively) determined by upstream dependencies. SBDG -> Sprin

Re: Spring Boot with Geode 1.10

This section of Spring Boot's Maven/Gradle Plugin explains it best... https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/gradle-plugin/reference/html/#managing-dependencies -j On Wed, Sep 25, 2019 at 1:24 PM John Blum wrote: > There is no version of Spring Boot (SBDG) currently built o

Re: [DISCUSS] Geode 1.11.0 dependency update

Hi Dick- Thanks for the reminder on an important topic. On quick review of *Nick's* proposal, which I like (well done), I would only add that if a patch release is cut (e.g. 1.9.1, 1.9.2) that dependencies be reviewed for updated patch releases as well. While different patch versions of dependen

Re: [ANNOUNCE] Apache Geode 1.10.0

Congrats!!! Nice work! On Thu, Sep 26, 2019 at 2:08 PM Dick Cavender wrote: > The Apache Geode community is pleased to announce the availability of > Apache Geode 1.10.0. > > Apache Geode is a data management platform that provides a database-like > consistency model, reliable transaction proce

Re: [DISCUSS] Support For LTS Version Of Geode

Put simply, from my perspective, I would like to see LTS versions of Apache Geode align with the *Spring Data* (*Release Trains*) support for Apache Geode. For example: SDG Lovelace/2.1 is based on Apache Geode 1.6.x. SDG Moore/2.2 is based on Apache Geode 1.9.x. Therefore, both Apache Geode 1.6

Re: [DISCUSS] Support For LTS Version Of Geode

1 > > On Mon, Sep 30, 2019, 8:09 PM John Blum wrote: > > > Put simply, from my perspective, I would like to see LTS versions of > Apache > > Geode align with the *Spring Data* (*Release Trains*) support for Apache > > Geode. > > > > For example: > > &g

Re: [DISCUSS] Support For LTS Version Of Geode

pache Geode needs to do any of what I am suggesting just for the Spring Data bits. But, it would make our lives simpler overall, which is why I am advocating for it. Final $0.02, -j On Mon, Sep 30, 2019 at 6:13 PM John Blum wrote: > Well, release durations are subjective to begin with.

Re: Token based authentication support added in Geode Develop

So application developer's will need to know to code their application client's to lookup the JWT token (from some store) and set HTTP request headers to send the token, or will this be handled automatically by a geode client? On Fri, Oct 4, 2019 at 11:37 AM Jinmei Liao wrote: > yes, correct, w

Re: Token based authentication support added in Geode Develop

got it On Mon, Oct 7, 2019 at 10:33 AM Joris Melchior wrote: > Yes, at the moment the we only support receiving a token provided in the > Authentication header field. We don't provide the standard endpoints for > token acquisition and refresh. > > On Fri, Oct 4, 2019 at 4:14

Re: [DISCUSS] Add GEODE-7261 and GEODE-7241 to release/1.9.2

+1 On Mon, Oct 14, 2019 at 11:19 AM Udo Kohlmeyer wrote: > +1 to including both. > > On 10/14/19 10:52 AM, Dick Cavender wrote: > > +1 for both fixes and the original list > > > > > > On Mon, Oct 7, 2019 at 5:00 PM Owen Nichols wrote: > > > >> Sounds like a big win for convenience, and clearly

Re: [DISCUSS] log4j errors/warnings

Be careful to only add logging dependencies as testRuntime dependencies. Do not add any logger implementation/provider (e.g. log4j-core, or otherwise) in either the compile-time or runtime scope. This also means that when users are using and running Apache Geode applications (regardless of context

Re: [DISCUSS] log4j errors/warnings

gt; to prevent the ERROR message. Any other input? > > > > On Fri, Oct 18, 2019 at 3:10 PM John Blum wrote: > > > > > Be careful to only add logging dependencies as testRuntime > dependencies. > > > Do not add any logger implementation/provider (e.g. log4j-core

Re: [VOTE] Apache Geode 1.9.2.RC1

+1 Built Spring Data for Apache Geode on 1.9.2 with success. On Tue, Oct 22, 2019 at 1:28 PM Jinmei Liao wrote: > +1 > > On Tue, Oct 22, 2019 at 11:47 AM Dave Barnes wrote: > > > +1 > > Downloaded, successfully built Geode and Geode-Native docs form source. > > > > On Tue, Oct 22, 2019 at 2:17

Re: Adding GEODE-7412 to 1.11 release

+1 On Fri, Nov 8, 2019 at 10:59 AM Patrick Johnson wrote: > +1 > > > On Nov 8, 2019, at 10:56 AM, Udo Kohlmeyer wrote: > > > > Hi there Geode Dev, > > > > I would like to request that we add > https://issues.apache.org/jira/browse/GEODE-7412 < > https://issues.apache.org/jira/browse/GEODE-7412>

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

Since the Servlet 3.1 spec is available and the current version is 4.0, why not consider 3.1 or even 4.0, actually? -j On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe wrote: > Hello Charles; thanks very much for bringing this up. > > I vote +1 on this proposal. > > Just to add a bit more details for

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

app > > and the Geode session module is working great except that I need to layer > > on an additional filter to ensure my session cookies are secure. > > > > > > -- > > > > Charles Smith > > > > Developer/Analyst > > > > Web Architecture a

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

-version.html Undertow: http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#getting-undertow ... http://undertow.io/ On Fri, Nov 15, 2019 at 2:57 PM John Blum wrote: > I would minimally bump it to 3.1 then. Not only does Servlet 3.1 open up > more doors (e.g. NIO), but i

Re: Cache.close is not synchronous?

+1 ^ 64! I found this out the hard way some time ago and is why STDG exists in the first place (i.e. usability issues, particularly with testing). On Mon, Nov 25, 2019 at 1:41 PM Kirk Lund wrote: > I found a test that closes the cache and then recreates the cache multiple > times with 2 second

Re: IndexType deprecation question

FYI... if you are using *Spring Data for Apache Geode* (SDG; spring-data-geode), then there is an SDG Index enum type [1] wrapping the deprecated Apache Geode Index enum type

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

+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 o

Re: IndexType deprecation question

gt; using > > > the IndexType enum or something similar. > > > > > > > > > > > > > > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior > > > wrote: > > > > > > > Thanks John. > > > > > > > > I

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

s 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 wrote: > > > > On Dec 1, 2019, at 2:40 PM, John Blum wrote: > > >

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

/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 wrote: > Indeed, both dependencies (geode-logging & geode-serial

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

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 wrote: > On Wed, Dec 4, 2019 at 11:16 AM John Blum wrote: > > > I am changing my vote to -1! > > > > I have filed GEODE-7531 <

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

suetabpanels:comment-tabpanel#comment-16988282 [2] https://issues.apache.org/jira/browse/GEODE-7531 On Wed, Dec 4, 2019 at 4:06 PM Dan Smith wrote: > On Wed, Dec 4, 2019 at 2:11 PM John Blum wrote: > > > This is not a test failure in SDG. SDG builds fine with Apache Geode > 1.11 >

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

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 s

Re: [VOTE] Inclusion of GEODE-7159 into 1.11

+1 On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender wrote: > +1 > > On Tue, Dec 17, 2019 at 3:01 PM Patrick Johnson > wrote: > > > +1 > > > > > On Dec 17, 2019, at 2:59 PM, Owen Nichols wrote: > > > > > > +1 > > > > > >> On Dec 17, 2019, at 2:58 PM, Udo Kohlmeyer wrote: > > >> > > >> Hi there Ap

Re: [VOTE] Inclusion of GEODE-7531 into 1.11

+1 On Tue, Dec 17, 2019 at 3:25 PM Dick Cavender wrote: > +1 > > On Tue, Dec 17, 2019 at 3:03 PM Patrick Johnson > wrote: > > > +1 > > > > > On Dec 17, 2019, at 3:01 PM, Owen Nichols wrote: > > > > > > +1 > > > > > >> On Dec 17, 2019, at 2:57 PM, Udo Kohlmeyer wrote: > > >> > > >> Hi there Ap

Re: [DISCUSS] What should we do with @Ignore tests?

+1 to Kirk's comments. Also, regarding (c), using AssumeThat [1] (or, alternatively & IMO preferrably, [2]) might provide some temporary relief. [1] https://junit.org/junit4/javadoc/latest/org/junit/Assume.html [2] https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/Assump

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

I thought I recall that the IndexType [1] was *deprecated* in favor of specific methods on the QueryService

Re: [Vote] Include GEODE-7752 into 1.12

+1 On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson wrote: > +1 > > On 2/5/20, 1:53 PM, "Udo Kohlmeyer" wrote: > > Hi there Geode dev, > > I would like to request that GEODE-7752 > (7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12. > > This piece of code is a ref

Re: OQL Method Authorizer Blog

+1 Good read, Juan. Nice job! On Fri, Feb 14, 2020 at 9:59 AM Jason Huynh wrote: > Great job Juan! Very informative and detailed read. > > On Fri, Feb 14, 2020 at 4:43 AM Nabarun Nag wrote: > > > Hi Geode Community, > > > > Please do visit the blog that Juan Ramos has put up on the OQL Method

Re: [DISCUSS] RFC: Shipping Geode patch releases

Real quick thought... IMO: 1. There should be patch (maintenance) releases for each major.minor, up to N-2 for a set period of time (e.g. 1.5 years), or until N-2 becomes N-3 where N-3 is no longer supported. 2. All important changes should be backported. I say "important" loosely since that shou

Re: [DISCUSS] RFC: Shipping Geode patch releases

ase (which is significant work) > if > > there was no important fix. > > Likewise I am concerned about waiting to ship a critical fix to our users > > or leave them with gaping security vulnerabilities when we have a fix, > but > > the next patch release train doesn'

Re: [DISCUSSION] - ClassLoader Isolation

Bruce - The primary gist of it is, client applications do not use the preconfigured classpath determined by Geode itself, such as would be the case when you start servers using *Gfsh*. Clients are not started with *Gfsh*, or any other Geode script for that matter. On Thu, Feb 27, 2020 at 8:53 AM

Re: [DISCUSS] RFC: Shipping Geode patch releases

gt; > > > > >> --Udo > >> > >> On 2/25/20 11:51 AM, Alexander Murmann wrote: > >>> Hi John, > >>> > >>> I think what you are calling out in 1. and 2. matches what was > discussed in > >>> the proposal and thread. P

Re: RFC - Client side configuration for a SNI proxy

+1 to using an Enum over separate methods. Less is more and having a smaller footprint (API) is better than an overloaded one where the number of methods could easily explode. That is smart design. Additionally, it is not hard to introduce a bit more abstraction if the parameters might vary by P

Re: RFC - Client side configuration for a SNI proxy

(); int getPort(); } -j On Mon, Mar 9, 2020 at 11:29 AM John Blum wrote: > +1 to using an Enum over separate methods. Less is more and having a > smaller footprint (API) is better than an overloaded one where the number > of methods could easily explode. That is sma

Re: RFC - Client side configuration for a SNI proxy

Yes, it's redundant (i.e. Enum + class type). However, having an Enum in addition to a specific type (1 reason I defaulted the getType() method) can still be useful, such as in a switch statement for example. Enums are, well, easier to enumerate (useful in Streams with filters). Maybe you are go

Re: RFC - Client side configuration for a SNI proxy

Support.stream(..) *.filter(ProxyConfiguration::isSecure)* .forEach(...); Again, completely contrived. Cheers! -j On Mon, Mar 9, 2020 at 11:14 PM John Blum wrote: > Yes, it's redundant (i.e. Enum + class type). > > However, having an Enum in addition to a specific type (1 reas

Re: RFC - Client side configuration for a SNI proxy

t; > > > The reason I'm not as keen on setProxy(ProxyConfiguration) is that it is > > hard for the user to discover the different types of ProxyConfiguration > > subclasses and know what is supported. > > > > -Dan > > > > On Mon, Mar 9, 2020 at 11:23

Re: Discussion on Deprecation

Additionally, it'd be ideal if the deprecated method were then adapted to delegate to the new approach. This will cut down on the number of required tests since then you only need a Unit Tests asserting the method performs the translation/delegating appropriately, unless of course the behavior is

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

+1 On Wed, Mar 18, 2020 at 11:52 AM Owen Nichols wrote: > +1 > > > On Mar 18, 2020, at 11:49 AM, Dick Cavender > wrote: > > > > +1 > > > > On Wed, Mar 18, 2020 at 11:43 AM Nabarun Nag wrote: > > > >> +1 > >> > >> On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh wrote: > >> > >>> Hello Dev list, >

Re: [VOTE] Apache Geode 1.12.0.RC1

SDG builds successfully with the Apache Geode 1.12.0 RC bits. It is a +1 from me when the rest of the problems are addressed. SDG build for Apache Geode (next), is here [1]. [1] https://jenkins.spring.io/job/spring-data-geode/job/master-next/ On Thu, Mar 26, 2020 at 10:28 AM Anthony Baker wro

Re: [VOTE] Apache Geode 1.12.0.RC4

SDG continues to build with the Apache Geode 1.12.0 RC4 bits. https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/ https://github.com/spring-projects/spring-data-geode/commits/master-next +1 On Fri, Mar 27, 2020 at 1:23 PM Anthony Baker wrote: > +1 > > Things I checked: > - exp

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

My first thought is cache close (i.e. RegionService.close() should be synchronous (by default), perhaps, with non-blocking options or options to wait for a set timeout as Jake suggested. This is a problem for *Integration Tests* (that start a peer cache instance, in-process or standalone) in gene

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

6234d908d7e0c4cc6b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225008165230328&sdata=GD77kAubDDWfP93zjYsNP61VMN4%2FKBAHcq95GwjeMBc%3D&reserved=0 > > > > On Tue, Apr 14, 2020 at 3:23 PM John Blum wrote: > > > >> My first thought is cache close (i.e. RegionService.clo

Re: Use of default methods in interfaces

Another way to think about this is: 1. First, default methods are not inherently bad. They are useful in many situations and can be "overridden" on implementing classes, if necessary. 2. A default method should be provided when the operation is not strictly required or if the implementation (proce

Re: Over usage of @SuppressWarnings

Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs): You can disable an inspection wher On Fri, May 8, 2020 at 11:52 AM Michael Oleske wrote: > For context, here is an example of PR that added warnings as error > https://github.com/apache/geode/pull/4816. Here is the JIRA

Re: Over usage of @SuppressWarnings

Let's try this again :P. +1 to Kirk's comments. Plus... Another tip (for IJ IDEA users, probably same for Eclipse and other IDEs): You can disable inspection for a warning that is otherwise benign (or not correct) *rather than* unnecessarily annotating the code with @SuppressWarnings. However,

Re: Over usage of @SuppressWarnings

@Donal - Well, if you have code like... public void someMethod(@Nullable Object value) { Assert.notNull(value, "..."); value.invokeSomeMethod(); ... } The compiler will often *warn* you that value might be null without a proper null check. That is, not all IDEs recognize "valid"

Re: Over usage of @SuppressWarnings

ese checks should be used judiciously in production code. -j On Fri, May 8, 2020 at 12:50 PM John Blum wrote: > @Donal - > > Well, if you have code like... > > public void someMethod(@Nullable Object value) { > > Assert.notNull(value, "..."); > > val

Re: Use of default methods in interfaces

of adding a new default interface method with an empty > implementation does concern me. Perhaps a new interface that extends the > original would be a more compile-time-verifiable way to express that new > optional methods have been added that only some but not all implementations > mig

Re: Over usage of @SuppressWarnings

Agreed, but the following (inside tests) does not work in all cases, i.e. Region region... Particularly if "region" is passed to a method with a different type signature. I am trying to find/think of the situation I encounter from time to time, even when I use the *wildcard* signature (i.e. Regi

  1   2   3   4   >