Thanks a lot Seb, your suggestions are always appreciated :)
Thanks for the sample, I see your troubles on ctor/builder, I think it
makes much more sense when the number of arguments is very large, like
the Generic(Keyed)ObjectPool(Factory). Do you have options to suggest?
Thanks in advance.
Abou
On 28 October 2010 18:50, Simone Tripodi wrote:
> Hi Seb,
> thanks for your feedbacks. Please read my questions inline your comments
>
>> 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 ct
Hi Seb,
thanks for your feedbacks. Please read my questions inline your comments
> 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?
I'm sorry but I didn't u
On 28 October 2010 15:16, Simone Tripodi 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
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).
Ma
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
On Thu, Oct 28, 2010 at 6:50 AM, Simone Tripodi
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 con
Hi all guys,
sorry to be late but I had to read all the resume before posting
something useful :P
So, briefly, just my 2 cents with the hope to contribute in a useful way:
About the JMX support, that could involve also the whole design, I
suggest on keeping out the Configuration but rather taking
