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. ConnectionPool, > ConnectionPoolService, and so on). Dang, I like both of these suggestions! 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 have to come up with new names for the methods - we can't have both an instance and a static method with the same name and args. Maybe still worth it Dale - are you suggesting a ConnectionPoolService that returns ConnectionPool instances? Would that mean ConnectionPool would extend Pool and we would deprecate Pool itself? -Dan On Fri, Dec 6, 2019 at 8:32 AM Darrel Schneider <dschnei...@pivotal.io> wrote: > +1 > > On Thu, Dec 5, 2019 at 4:40 PM Dan Smith <dsm...@pivotal.io> 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 friends > > had trying to mock Pools and remove the need for those projects to try to > > inject mock Pools into a Geode singleton. > > > > > > > https://cwiki.apache.org/confluence/display/GEODE/Replace+singleton+PoolManager+with+ClientCache+scoped+service > > > > Thanks, > > -Dan > > >
