[DISCUSSION] De/un-deprecate IndexType ENUM

Hi All, Looking for feedback on the proposal to [un/de]deprecate the IndexType ENUM on Geode. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477 Thanks, Joris. -- *Joris Melchior * CF Engineering Pivotal Toronto 416 877 5427 “Programs must be written for people to

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

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

Proposals - Request For Comments (RFC) process

Just as a reminder we do have a light weight process for handling changes in "public" areas like configuration, monitoring, command line tools, etc. So as we get close to proposing changing something for the better we might want to make sure we are following the process to ensure we are doing the

Re: Certificate Based Authorization

+1 On 12/2/19 1:29 AM, Mario Kevo wrote: Hi, There is another potential functionality we would like to discuss and get some comments for. The idea is TLS certificate based authorization. Currently, if a user wants secure communication (TLS) + authorization, he needs to enable TLS and

Re: Certificate Based Authorization

+1 On Mon, Dec 2, 2019 at 12:26 PM Jacob Barrett wrote: > +1 > > > On Dec 2, 2019, at 6:47 AM, Jens Deppe wrote: > > > > Hi Mario, > > > > Definitely sounds like a good idea! Feel free to write up a RFC proposal > > with more details. > > > > Thanks > > --Jens > > > > On Mon, Dec 2, 2019 at

Re: IndexType deprecation question

Okay, that is good feedback. I lean towards un-deprecating as well. Let me write a draft proposal for some changes so everyone can chime in and hopefully we'll have a workable target at the end of it. Thanks, Joris. On Mon, Dec 2, 2019 at 1:00 PM John Blum wrote: > My vote would be to

Re: IndexType deprecation question

My vote would be to UNDEPRECATE the IndexType in Apache Geode. There are several codepaths in SDG that use the IndexType to make certain decisions. I also think having an Enum is much more flexible than having a method per Index type, particularly since you can use Enum values in switch

Re: IndexType deprecation question

Hi Joris, Just some guesses and no actual answer from me here: The deprecation of the index type was before HASH indexes were created, and my guess was due to the introduction of the "new at the time" query service apis (the javadoc:@deprecated As of 6.6.1. Check {@link QueryService} for

Re: Odg: Lucene upgrade

Hi Mario, Sorry I reread the original email and see that the exception points to a different problem.. I think your fix addresses an old version seeing an unknown new lucene format, which looks good. The following exception looks like it's the new lucene library not being able to read the older

Re: Certificate Based Authorization

+1 > On Dec 2, 2019, at 6:47 AM, Jens Deppe wrote: > > Hi Mario, > > Definitely sounds like a good idea! Feel free to write up a RFC proposal > with more details. > > Thanks > --Jens > > On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo wrote: > >> Hi, >> >> >> >> There is another potential

Re: IndexType deprecation question

Hi Jason, At this point it is not about creating but returning the Region with an indicator in the management API without using deprecated parts. Under the covers the QueryService java api still uses the IndexType ENUM and had assumed that an alternative would be provided when something is marked

Re: IndexType deprecation question

Hi Joris, How are you creating the index? If using the QueryService java api, there should be createKeyIndex() and createIndex() methods. These methods should create the primary key index and the functional index. I am not sure if there is an alternative in gfsh... it might still be using the

Re: [DISCUSS] - Move gfsh into its own submodule

Thanks for the positive feedback. This proposal is accepted and development will proceed. --Jens On Mon, Nov 25, 2019 at 9:27 AM Dale Emery wrote: > +ힹ > — > Dale Emery > dem...@pivotal.io > > > > > On Nov 22, 2019, at 8:39 AM, Jens Deppe wrote: > > > > Hello All, > > > > We'd like to propose

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

For the purpose of moving this forward, I have merged PR #4311 [1]. From a runtime POV this now requires a minimum 3.0 servlet compatible container. Documented minimum, however, is at least 3.1. I suggest that if anyone would like to see documented newer support that that should be proposed

Re: Certificate Based Authorization

Hi Mario, Definitely sounds like a good idea! Feel free to write up a RFC proposal with more details. Thanks --Jens On Mon, Dec 2, 2019 at 1:30 AM Mario Kevo wrote: > Hi, > > > > There is another potential functionality we would like to discuss and get > some comments for. The idea is TLS

Odg: Lucene upgrade

I started with implementation of Option-1. As I understood the idea is to block all puts(put them in the queue) until all members are upgraded. After that it will process all queued events. I tried with Dan's proposal to check on start of LuceneEventListener.process() if all members are

Certificate Based Authorization

Hi, There is another potential functionality we would like to discuss and get some comments for. The idea is TLS certificate based authorization. Currently, if a user wants secure communication (TLS) + authorization, he needs to enable TLS and access control. The user also needs to handle