yes, understood and agreed. BTW I still find redundant that the same field, used with the same semantic, is present in Config,Pool and Factory, my proposal was about keeping the Config only - immutable fields can be declared there - and remove config parameters from Factory/Pool, that will require a Config or use the default one. Otherwise any suggestion is much more than welcome, it would be a shame IMHO not improving the design. Thanks for discussing about this topic, have a nice day, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Oct 16, 2010 at 2:25 AM, sebb <seb...@gmail.com> wrote: > On 15 October 2010 17:01, Simone Tripodi <simone.trip...@gmail.com> wrote: >> Hi all guys, >> there are Generic(Keyed)ObjectPool(Factory) that (in pairs, Pool and >> related factory) share the same kind of information, replicated in the >> related Config class. >> >> I wonder if we can improve that design and remove that information >> redundancy: I propose to keep the Config classes only, put them not as >> inner class, in order to remove the circular dependency between >> factory/pool and remove also the not so comfortable (at least for me) >> n-arguments constructors. >> So, the GenericObjectPool, instead of having all these constructors, >> could work only with: >> >> public GenericObjectPool(PoolableObjectFactory<T> factory) { >> this(factory, new Config()); >> } >> >> public GenericObjectPool(PoolableObjectFactory<T> factory, Config config) { >> this.factory = factory; >> this.config = config; >> } >> >> both factory and config can be final; if users need to reconfigure the >> pool at runtime, invoke the setter and modify the interested value >> >> pool.getConfig().setWhenExhaustedAction(WhenExhaustedAction.GROW); >> >> I'd extend later the same approach also to other Pools... WDYT? > > The advantage of using ctor parameters is that they can be saved in a > final field. > The config approach is OK for parameters that need to remain mutable, > but can impose additional synch. requirements for settings that must > not be changed during the life of the pool. > > For example, I suspect LIFO should be immutable, and should therefore be > final. > >> Many thanks in advance, >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
