On 10/12/10 11:26 AM, sebb wrote:
On 12 October 2010 16:03, Phil Steitz<phil.ste...@gmail.com> wrote:
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.
The field in question is _maxSleeping which has already been marked as:
"@deprecated to be removed in pool 2.0. Use {...@link #getMaxSleeping()}"
The field is settable by using the appropriate constructor.
I thought we had decided to make such fields final as part of POOL-169?
Indeed, it seems it was psteiz who committed r990437 which added the
deprecated comment ...s
I meant to deprecate the protected field - meaning that direct
access would not be supported in 2.0. I did not mean to imply that
the decision had been made that there would be no setter. We need
to talk about this general topic. I have a few times had occasion
to increase maxActive and make other modifications to pools at
runtime. I could personally live without this, but it is a big
difference that we should allow the community to weigh in on if we
are talking here about all pool properties.
Phil
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
---------------------------------------------------------------------
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
