Hi,
Since this proposal is open for almost three weeks,
and we have 2 plus one,
We will continue with proposed solution.
Regards,
Mario
Šalje: Mario Ivanac
Poslano: 19. studenog 2019. 12:26
Prima: dev@geode.apache.org
Predmet: Proposal of new config property "
Hi Mario,
I did have a question / suggestion about this proposal (possibly on a
different thread). Would you mind responding to that before proceeding
please. I'll just paste it in here too.
> Jens Deppe
> Tue, Nov 19, 4:42 PM
> to dev
> I'd like to add my comment from the original PR here agai
Hi,
I agree with your proposal/question,
and implementation will follow it.
BR,
Mario
Šalje: Jens Deppe
Poslano: 9. prosinca 2019. 15:55
Prima: dev@geode.apache.org
Predmet: Re: Odg: Proposal of new config property "ssl-server-name-extension"
Hi Mario,
I did h
> I imagine once the Management v2 API's are GA (and feature complete), I
don't see a reason why /gfsh/ should not be a stand alone module. It
would definitely have to be updated to use the new v2 API's, which
should not have any direct dependency on geode-core any more.
There also is a big questi
+1
Aaron
> On Dec 6, 2019, at 10:49 AM, Jacob Barrett wrote:
>
>
>
>> On Dec 6, 2019, at 9:40 AM, Dan Smith wrote:
>>
>> Regarding changing PoolManager to
>> an interface, I guess originally I wasn't thinking we would still be
>> backwards compatible if we did that. But as I think about it
Reading over the docs for gfsh - I don't support removing any functionality
from a top level command perspective.It should be noted that I didn't
go deeper then the top level commands, there might be some sub option on
some command that could be dropped or tweaked.
Charlie
On Mon, Dec 9, 201
On Fri, Dec 6, 2019 at 10:45 AM Dale Emery wrote:
>
> > Dale - are you suggesting a ConnectionPoolService that returns
> ConnectionPool instances?
>
> Yes.
>
> > Would that mean ConnectionPool would extend Pool and we would deprecate
> Pool itself?
>
> Maybe extend. I worry about extending, for t
