Hi,
I wrote up a proposal for deprecating of the singleton PoolManager in favor
of a ClientCache scoped service. Please review and comment on the below
proposal.
I think this should address the issues that Spring Data Geode and friends
had trying to mock Pools and remove the need for those projec
+1
To the extent possible without breaking existing APIs, please name the new
stuff to indicate what’s in the pool (E.g. ConnectionPool,
ConnectionPoolService, and so on).
—
Dale Emery
dem...@pivotal.io
> On Dec 5, 2019, at 4:40 PM, Dan Smith wrote:
>
> Hi,
>
> I wrote up a proposal for d
+1
On Thu, Dec 5, 2019 at 7:40 PM Dan Smith wrote:
> Hi,
>
> I wrote up a proposal for deprecating of the singleton PoolManager in favor
> of a ClientCache scoped service. Please review and comment on the below
> proposal.
>
> I think this should address the issues that Spring Data Geode and fri
This is a great idea!
On thought though, did you consider just converting the existing PoolManager to
an interface leaving the static methods intact but deprecated? I would think
this would make existing code pretty easy to refactor over to the new code with
minimal changes. If you thought abou
+1
On Thu, Dec 5, 2019 at 4:40 PM Dan Smith wrote:
> Hi,
>
> I wrote up a proposal for deprecating of the singleton PoolManager in favor
> of a ClientCache scoped service. Please review and comment on the below
> proposal.
>
> I think this should address the issues that Spring Data Geode and fri
Jake wrote:
> On thought though, did you consider just converting the existing
> PoolManager to an interface leaving the static methods intact but
> deprecated?
>
Dale wrote:
> To the extent possible without breaking existing APIs, please name the new
> stuff to indicate what’s in the pool (E.g.
> 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 two reasons.
First, extending would make the new interface dep
> 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 I think that
> might be ok. One slight issue with that approach is that we h
+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
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
It looks like we never came to a consensus on this thread, and meanwhile
the urgency for this fix has gone away. The original urgency was to give
spring data geode a way to avoid using internal APIs, but that has been
fixed a different way in SDG.
I still think this would be a good change to make
11 matches
Mail list logo
