Hi again James, all, please review my last commit[1], I refactored the Config and related (Keyed)StackObjectPool(Factory), I tried to implements the concepts we've been discussing in this thread. If this fits to our vision, I can follow applying the refactor to Generic(Keyed)ObjectPool(Factory). Many thanks in advance!!! All the best, Simo
[1] http://svn.apache.org/viewvc?rev=1028302&view=rev http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Oct 28, 2010 at 2:46 PM, Simone Tripodi <simone.trip...@gmail.com> wrote: > Hi James, > thanks, understood. I take in charge yet another cycle of refactoring, > I'll ping you all when in trouble about something :) > Have a nice day and thanks for the feedbacks! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Thu, Oct 28, 2010 at 2:12 PM, James Carman > <ja...@carmanconsulting.com> wrote: >> On Thu, Oct 28, 2010 at 6:50 AM, Simone Tripodi >> <simone.trip...@gmail.com> wrote: >>> That's why I wouldn't follow the option #2; but please, explain me >>> which are the side effects of that design, so I can avoid to repeat >>> the same mistake in the future. >>> >> >> If you make the config objects immutable, you can just keep the config >> references around and skip the copying in the reconfigure() method. I >> don't think it would be difficult to implement things this way. We >> don't want to let the JMX stuff dictate our API too much. The JMX >> stuff can be less "elegant" for sure. Consider it to be just a UI >> layer on top of our stuff. >> >> --------------------------------------------------------------------- >> 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
