On 28 October 2010 15:16, Simone Tripodi <simone.trip...@gmail.com> wrote: > 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.
The public StackObjectPoolConfig ctor repeats the settings available in the nested Builder. I'm not sure I see the point of having both. Or perhaps the ctor is supposed to be private? Also, I don't like the way the ctor resets the parameters if they are out of range, especially as this is not documented. == The StackObjectPool ctor calls the overridable method reconfigure(StackObjectPoolConfig) which is not safe when subclassing. Easily fixed by having a private method with the shared code. Also, reconfigure() updates maxSleeping, but is not synchronized, so may not publish maxSleeping correctly. Similar considerations apply to the other classes. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
