Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 54792 invoked from network); 2 Dec 2002 00:39:49 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Dec 2002 00:39:49 -0000 Received: (qmail 12052 invoked by uid 97); 2 Dec 2002 00:40:31 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 11955 invoked by uid 97); 2 Dec 2002 00:40:31 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 11829 invoked by uid 50); 2 Dec 2002 00:40:30 -0000 Date: 2 Dec 2002 00:40:30 -0000 Message-ID: <20021202004030.11820.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 14983] New: - GenericObjectPool should allow for manual population of the pool X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14983 GenericObjectPool should allow for manual population of the pool Summary: GenericObjectPool should allow for manual population of the pool Product: Commons Version: 1.0.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Pool AssignedTo: commons-dev@jakarta.apache.org ReportedBy: sschwell@yahoo.com I need an ObjectPool which blocks when exhausted and is populated manually by the client. Wouldn't it be nice if GenericObjectPool provided this? I don't see how adding this capability would detract from any existing functionality. All we need is a new method, addNewObject(), whose implementation is very similair to, but NOT the same as, returnObject(). Also, the factory should be truly optional. it makes the class more flexible, without any sacrifice in functionality. the current implementation which allows construction of a GenericObjectPool without a factory, but throws NullPointerException when used, is broken. There's no way that can be considered robust code. -- To unsubscribe, e-mail: For additional commands, e-mail: