Re: [DISCUSS] Move geode to the attic

For clarification, I believe Sonatype does not allow anything to be removed from Maven Central once it has been published. The bits are there to stay, permanently, and there are no exceptions AFAIK. -j From: Mark Bretl Date: Tuesday, October 18, 2022 at 1:14 PM To: John Blum Cc: dev

Re: [DISCUSS] Move geode to the attic

How does the VMware’s non-disclosed date commitment factor into this equation? I mean, clearly the Apache Geode 1.15 release has a lifecycle and support timeline, even if the community (and a new PMC) does drive the project any further? What happens when CVEs, or critical bugs (involving data

Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo

Personally, I believe doc is a critical component to any software project, especially a project like Apache Geode, and so, is the project really “complete “(or should thee codebase really be frozen during a release) if the doc is not done or consistent yet? Having the doc be part of the

Re: [PROPOSAL] RFC for migrating from springfox to springdoc

Spring Data for Apache Geode (and the upcoming Spring Data for VMware Tanzu GemFire) very much depends on and uses the Management REST API. From: Jinmei Liao Date: Thursday, May 5, 2022 at 5:40 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] RFC for migrating from springfox to springdoc

Re: Update the build to use Gradle 7.4

Hi Ryan- Nice work on the Gradle 7.4 upgrade! I know first-hand how challenging this effort is since I am (currently) going through the same exercise with all the Spring for Apache Geode projects. In fact, minimally, Gradle 7.3 is required to build with Java 17 [1]. Be careful when switching

Re: [VOTE] Apache Geode 1.14.0.RC2

+1 Spring Data for Apache Geode (SDG) Q/2.6 builds successfully with Apache Geode 1.14.0 (RC2). From: Jianxia Chen Sent: Thursday, September 2, 2021 2:49 PM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.14.0.RC2 +1 * Use binary distribution to

Re: JDK 16 Support?

r.java:162) at org.apache.geode.cache.lucene.internal.LuceneBucketListener.lambda$afterPrimary$0(LuceneBucketListener.java:40) ____ From: John Blum Sent: Monday, May 10, 2021 11:19 AM To: dev@geode.apache.org ; u...@geode.apache.org Subject: Re: JDK 16 Support? Thanks Bill (everyone) for the i

Re: JDK 16 Support?

(landed on 3/30/21 on the develop branch) might get you a little bit further. That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf eliminated the reflective field access in favor of some simpler down-casting. On Wed, May 5, 2021 at 9:06 AM John Blum mailto:jb...@vmware.com>> wrote: Hi A

Re: JDK 16 Support?

version of Java and clearly we would need to fix errors like this. Do you see a need to support Java 16 now? Anthony On May 5, 2021, at 7:57 AM, John Blum mailto:jb...@vmware.com>> wrote: What is the plan to support Java 16 for Apache Geode? Timeframe? Running Apache Geode on a J

JDK 16 Support?

What is the plan to support Java 16 for Apache Geode? Timeframe? Running Apache Geode on a Java 16 Runtime produces errors like the following: - org.apache.geode.InternalGemFireException: unable to retrieve underlying byte buffer - at

Re: [VOTE] Requiring final keyword on every parameter and local variable

ress intent. And, most importantly, function should match intent. -j From: John Blum Sent: Wednesday, April 21, 2021 6:02 PM To: dev@geode.apache.org Subject: Re: [VOTE] Requiring final keyword on every parameter and local variable I vote -1 for (generally) u

Re: [VOTE] Requiring final keyword on every parameter and local variable

se unnecessary finals (for people that don't want to see them). On 4/21/21, 4:36 PM, "John Blum" wrote: I wouldn't recommend Lombok for production code, primarily because it generates code. Generated code occasionally leads to unintended consequences or incompatibilities

Re: [VOTE] Requiring final keyword on every parameter and local variable

nd I remember John Blum using it on some projects. I would like to study it and do some perf testing on it before supporting it for Geode though. In general, I don't like generated code and it looks like at least some of the features involve generated code -- that's the only potential downside fo

Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1

+1 Spring Data for Apache Geode 1.12.2 built successfully. From: Dave Barnes Sent: Monday, April 19, 2021 9:19 AM To: dev@geode.apache.org Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.12.2.RC1 +1 Built and reviewed User Guide and API docs. LGTM. On Wed,

Re: [DISCUSS] removal of experimental Protobuf client/server interface

To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Protobuf client/server interface That's true John, but the Protobuf i/f is using the same code as the REST server to serialize/deserialize JSON documents. It isn't any better at it. On 3/29/21, 10:33 AM, "John Blum"

Re: [DISCUSS] removal of experimental Protobuf client/server interface

Correction! Although a different/separate issue, Geode's JSON document handling is incomplete at best. It does not properly handle all forms of JSON or types (e.g. Java 8 Data/Time types). From: Bruce Schuchardt Sent: Thursday, March 25, 2021 8:01 AM To:

Re: Proposal: new Geode property CRITICAL_HEAP_PERCENTAGE

Why is calling InternalResourceManager.setCriticalHeapPercentage(..) necessary? This configuration setting is accessible from the public API GemFireCache.getResourceManager().setCriticalHeapPercentage(..). Perhaps this configuration property can be specific to the Geode Redis module?? For

Re: [VOTE] Apache Geode 1.12.1.RC4

To be clear SDG Neumann/2.3.x builds with Apache Geode 1.12.1, correctly. +1 From: John Blum Sent: Wednesday, February 24, 2021 1:52 PM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.12.1.RC4 +1 Spring Data for Apache Geode builds with Apache

Re: [VOTE] Apache Geode 1.12.1.RC4

+1 Spring Data for Apache Geode builds with Apache Geode 1.12.1 RC bits. From: Dave Barnes Sent: Wednesday, February 24, 2021 10:34 AM To: dev@geode.apache.org Subject: Re: [VOTE] Apache Geode 1.12.1.RC4 +1 Docs. - Geode API docs header correctly updated to

Re: [PROPOSAL] Change the default value of conserve-sockets to false

I agree with Dan, here, along with the consensus that false is the better default (in most cases). So, I simply want to re-iterate the importance of "documentation" in whatever direction we decide. There are, without a doubt, both pros and cons to each configuration arrangement (true of

Re: Requests taking too long if one member of the cluster fails

rres Sent: Saturday, November 21, 2020 1:40 PM To: dev@geode.apache.org Cc: miguel.g.gar...@ericsson.com Subject: Re: Requests taking too long if one member of the cluster fails Thanks @John Blum<mailto:jb...@vmware.com> for your detailed explanation! It helped me to better understand how

Re: Requests taking too long if one member of the cluster fails

DISCLAIMER: I am not knowledgeable about the Native Client (implementation) nor am I commenting specifically on the perf you are seeing, which can have many factors. However, in general... Given you are performing "put" operations on a PR, then for consistency reasons, Geode is always going to

Re: [PROPOSAL] Change the default value of conserve-sockets to false

The downside of conserve-sockets = false is that you are (essentially) back to a Thread|Socket / Request model (though Geode limits this system resource consumption to a degree by the use of Thread Pools in p2p distribution layer) and thus, you can run out of file descriptors (per newly opened

Re: How to add a new REST end point in Cluster Management Service

Hi Jinmei- I put feedback and other comments in the Wiki page. Regards, John From: Jinmei Liao Sent: Monday, October 26, 2020 10:53 AM To: dev@geode.apache.org Subject: How to add a new REST end point in Cluster Management Service Hi, Geode developers, I

Re: [DISCUSS] ServiceRegistry RFC

FYI.. Spring's ApplicationContext is not necessarily Immutable (e.g. you can register a bean instances after the container has started, or mutate the Environment in some way as necessary by the application for lazy resources/initialization), but the bean configuration is "frozen" (effectively

Re: [DISCUSS] ServiceRegistry RFC

A word of caution here... I'd like to see us start moving away from "internal" APIs even, as much as possible. Moving away from Singletons is no-brainer, but less obvious, is moving things to proper public APIs and SPIs so that frameworks and tooling can extend Geode in interesting ways. SDG

Re: [DISCUSS] One more 1.13 change

+1 From: Dan Smith Sent: Monday, September 28, 2020 12:21 PM To: dev@geode.apache.org Subject: [DISCUSS] One more 1.13 change Hi, I'd like to backport this change to support/1.13 as well GEODE-8522: Switching exception log back to debug -

Re: [VOTE] Apache Geode 1.13.0.RC1

+1 Built Spring Data for Apache Geode (SDG) Ockham/2.4(2020-0-0) on Apache Geode 1.13.0 (RC1), using the staging repository, successfully! -John SDG Lead From: Apache Sent: Tuesday, September 8, 2020 4:07 PM To: dev@geode.apache.org Subject: Re: [VOTE]

Re: [Proposal] - RFC etiquette

+1 From: Patrick Johnson Sent: Thursday, July 9, 2020 1:31 PM To: dev@geode.apache.org Subject: Re: [Proposal] - RFC etiquette +1 > On Jul 9, 2020, at 1:18 PM, Udo Kohlmeyer wrote: > > Hi there Geode Dev's > > I would like to propose the following changes to

Re: geode docker question

Hi Barry- Have a look at this... https://docs.spring.io/spring-boot-data-geode-build/1.3.x/reference/html5/#geode-docker I recently put this together as part of the SBDG 1.3 GA release. It contains references to other pertinent documentation as well. There aren't any pre-canned Docker Images

Re: Over usage of @SuppressWarnings

; > How does everyone feel about situations involving raw types? > > > > Such as public interface A is returning Region and not Region is > that an acceptable suppression? > > > > Thanks, > > Mark > > > >> On May 8, 2020, at 1:20 PM, John Blum w

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.

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

these 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: 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

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.

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

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

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

9138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637225008165230328sdata=GD77kAubDDWfP93zjYsNP61VMN4%2FKBAHcq95GwjeMBc%3Dreserved=0 > > > > On Tue, Apr 14, 2020 at 3:23 PM John Blum wrote: > > > >> My first thought is cache close (i.e. RegionService.close() should be > &

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

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: > -

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

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: 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: 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 PM John Blum wrote

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 reason I

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

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

+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

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: [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

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't depart f

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

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

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

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: [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]

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

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

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

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

ent-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 > > (and all

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.

31 [2] https://issues.apache.org/jira/browse/GEODE-7531?focusedCommentId=16988096=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-serialization) are > listed a

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

h 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: IndexType deprecation question

> > the IndexType enum or something similar. > > > > > > > > > > > > > > > On Fri, Nov 29, 2019 at 12:18 PM Joris Melchior > > > wrote: > > > > > > > Thanks John. > > > > > > > > I'm trying to us

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

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: 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: 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: 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 and Develop

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

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

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

Re: [DISCUSS] log4j errors/warnings

o 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, or

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

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: 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 PM J

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,

Re: [DISCUSS] Support For LTS Version Of Geode

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. What

Re: [DISCUSS] Support For LTS Version Of Geode

; > 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: > > >

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

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

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

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 on Apa

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

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

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

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,

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

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] - Cutting of release 1.9.2

-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 wrote:

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

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.

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

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 > > > > On Tue, Sep

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

ve 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

`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: [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

Re: [VOTE] Apache Geode 1.9.1.RC3

ought. -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: [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

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! > >

  1   2   3   >