You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tom Muldoon <to...@firstbest.com> on 2007/08/27 13:17:18 UTC

[pool] Why are ensureMinIdle and calculateDeficit private?

I extended the GenericObjectPool a while back to create a typesafe
implementation (which is exposed as an Mbean) and I was planning on
overriding the startEvictor method to use my own Evictor implementation
(which simply trackes when it is scheduled to run next) and I was
surprised to discover that ensureMinIdle and calcuateDeficit are private
- I expected both to be protected.  So, now it appears that I will have
to re-implement both methods. With that said, any chance they could be
made protected in the future? 

 

Thanks in advance, Tom


Re: [pool] Why are ensureMinIdle and calculateDeficit private?

Posted by Phil Steitz <ph...@gmail.com>.
On 8/27/07, Tom Muldoon <to...@firstbest.com> wrote:
> I extended the GenericObjectPool a while back to create a typesafe
> implementation (which is exposed as an Mbean) and I was planning on
> overriding the startEvictor method to use my own Evictor implementation
> (which simply trackes when it is scheduled to run next) and I was
> surprised to discover that ensureMinIdle and calcuateDeficit are private
> - I expected both to be protected.  So, now it appears that I will have
> to re-implement both methods. With that said, any chance they could be
> made protected in the future?
>
>

Sorry for the delayed response.  I can't speak for the initial
designers on this one, but I suspect that they were concerned about
maintaining backward compatibility and ongoing support for these
methods.  We view protected methods as part of the API of commons
components, so we are conservative in what we expose in this way.

I don't see it as likely that these methods will be exposed.  I would
not want to do it because a) the contracts are tricky to express so
that general use in subclasses is safe and b) it is already hard
enough to keep up with the concurrency issues associated with the
current API.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org