I'm planning a helper class for Pool similar to the java.util.Collections class. Below are the static methods I'm thinking of implementing. Let me know if I forgot anything, misnamed anything, added too much.
* Two synchronizedPoolableFactory(factory) methods that take a [Keyed]PoolableObjectFactory and wrap them in a synchronization wrapper. * A few prefill(pool, count) methods that call addObject() the specified number of times. * Some checkMinIdle(pool, minIdle, period) methods that use a java.util.Timer and periodically check the pool and call addObject as needed to keep a minimum idle object count. Personally I don't like Pools that try to keep pre-made idle objects in the pool. Best case it increases start up time, worst case consumes cpu and memory that never gets used. Still, some people people think they need this feature and this gives them a very similar feature without complicating the pool implementation. * A series of adapt(...) methods that allow the user of a KeyedObjectPool or KeyedPoolObjectFactory where a non-keyed implementation is expected or vice-versa. The key would be specified at the time the adapt method is called and could not be changed. I'm a little iffy in this feature. In included it because the composite pool implementation does something similar to allow a KeyedObjectPool be literally implemented as a map of ObjectPools. From the point of view of the programmer using pool I'm not so sure this feature is needed enough to justify itself as part of the client api. -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
