[
https://issues.apache.org/jira/browse/GEODE-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988917#comment-16988917
]
Dan Smith commented on GEODE-7532:
----------------------------------
Would it also fix the issue to deprecate the PoolManager singleton and move the
Pool creation logic to ClientCache? That would allow frameworks to wrap
ClientCache, PoolFactory, and Pool consistently.
If that works, I think that will be a better fix - we're trying to get rid of
singletons in the Geode code base anyway.
FYI, the Pool interface is not an interface that allows plugging in different
connection pooling implementations. It is the *public* view of an internal
object within Geode (much like Region, QueryService, AsyncEventQueue, etc.).
Injecting a Pool into PoolManagerImpl is not likely to work except for maybe
the most trivial cases of PoolManager.find(Pool). Once you actually try to use
the pool, like attaching it to region, it's going to fail because it needs a
real internal PoolImpl that has all of the actual methods and functionality to
send messages to servers, etc. Really, PoolManagerImpl should have lists of
PoolImpls, I'm not sure why it has an internal collection of Pool objects that
are later cast.
> PoolManagerImpl.register(:Pool) and PoolManagerImpl.unregister(:Pool) should
> be declared on the PoolManager interface
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: GEODE-7532
> URL: https://issues.apache.org/jira/browse/GEODE-7532
> Project: Geode
> Issue Type: Improvement
> Components: client/server
> Reporter: John Blum
> Priority: Major
>
> For all general uses, and especially for framework and tooling purposes, both
> {{register(:Pool)}} and {{unregister(:Pool)}} methods of the
> {{PoolManagerImpl}} class should be part of the {{PoolManager}} interface
> given both methods are technically part of the "{{public}}" API despite
> {{PoolManagerImpl}} being "deemed" part of some "internal" API (which is
> completely arbitrary and irrelevant since it is not properly enforced by the
> language constructs of Java).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
