[ http://issues.apache.org/jira/browse/POOL-91?page=comments#action_12458919 ] Ben Speakmon commented on POOL-91: ----------------------------------
I'm interested in the decorated factory approach -- how would you see that API working? Sandy, your point about the concurrent library being fundamentally different in approach from commons-pool is well taken; perhaps it would be helpful if I explained how I've seen pool. I thought of pool as a general-purpose pool including support for threads as well as POJOs, and under that assumption the ThreadPoolExecutor approach made good sense. Of course when you're pooling heavyweight objects that don't implement Runnable, the thread-based approach doesn't really apply, and the callback is overkill. If pool isn't about threads, and the answer to someone who wants thread pooling is to either use JDK 5 or util.concurrent, then I'm perfectly happy with that. However, on a purely API basis, I'd still like to entertain the idea of not forcing the client to catch a checked exception when borrowing an object. A factory approach could lead that way, and I'd be interested to see where that leads. > StackObjectPool.borrowObject infinate loop when makeObject returns null > ----------------------------------------------------------------------- > > Key: POOL-91 > URL: http://issues.apache.org/jira/browse/POOL-91 > Project: Commons Pool > Issue Type: Bug > Reporter: Sandy McArthur > Assigned To: Sandy McArthur > Attachments: sample-borrow-fail-pool-policy.tar.bz2 > > > StackObjectPool.borrowObject has a infinate loop when makeObject returns null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
