On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:50 PM, sebb<seb...@gmail.com> wrote:
On 12 October 2010 10:20, Simone Tripodi<simone.trip...@gmail.com> wrote:
Hi all guys,
while fixing the deprecated properties in classes like
StackKeyedObjectPool[1], I noticed this class instance was
re-configured during the test[2] (see line 126); is the
"reconfigure-in-runtime" a pool feature we want? I'm asking because
I've never experienced the pool reconfiguration (I've never had the
need to do it) so I honestly don't know which is the wished behavior.
In the scenario we want to keep this feature, since I'm converting
fields as private, I need to add setters.
Just let me know!!! Have a nice day,
AFAIK, the tests that modify the configuration are to be dropped once
the variables are made private.
The idea was not just to make the variables private, but to make them
final as far as possible to improve thread safety.
Perhaps Phil can confirm this?
The only property that I think we have agreed at this point to make
immutable is the factory. I am open to talking about making other
properties immutable, but I think we should get some broader input
on this topic.
Phil
Simo
[1] http://s.apache.org/bjw
[2] http://s.apache.org/qB
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
