In [POOL-178] I have created a patch that IMO should make it easier for us to
further refactor code.
In brief, OP/BOP and KOP/BKOP do not have a common parent interface/class. This
patch remedies this by pulling up the close/clear/getNumActive/getNumIdle
methods into a new interface and class
On Fri, Oct 29, 2010 at 2:24 PM, sebb wrote:
>
> I had overlooked that aspect ...
>
> If some changes are more expensive to perform, then the method might
> want to determine which items have changed, rather than just
> reconfiguring everything.
> There may be some changes that don't require a poo
On 29 October 2010 18:51, James Carman wrote:
> On Fri, Oct 29, 2010 at 12:48 PM, sebb wrote:
>>
>> Yes, but the code will still need to use the read lock whenever it
>> reads the field to ensure changes are propagated correctly.
>> Both the writer and reader threads need to synch. on the same lo
On Fri, Oct 29, 2010 at 12:48 PM, sebb wrote:
>
> Yes, but the code will still need to use the read lock whenever it
> reads the field to ensure changes are propagated correctly.
> Both the writer and reader threads need to synch. on the same lock in
> order for changes to be published safely.
>
>
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On 29 October 2010 17:06, James Carman wrote:
> On Fri, Oct 29, 2010 at 11:40 AM, sebb wrote:
>>
>> If Config instances are immutable, then there is no need to synch.
>> access to their contents.
>> However, if the field which stores the Config instance is not final,
>> then all accesses to that
On Fri, Oct 29, 2010 at 11:40 AM, sebb wrote:
>
> If Config instances are immutable, then there is no need to synch.
> access to their contents.
> However, if the field which stores the Config instance is not final,
> then all accesses to that need to be synch. - or the field could be
> volatile.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Friday, October 29, 2010 21:41
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> Another possibility:
>
> If Config instances are immutable, then there is no need to synch.
> acc
Another possibility:
If Config instances are immutable, then there is no need to synch.
access to their contents.
However, if the field which stores the Config instance is not final,
then all accesses to that need to be synch. - or the field could be
volatile.
Once the code has obtained the confi
Yet another question: are factories reconfigurable? Because it seems
only Stack(Keyed) Factories are, but Generic* not, we should allineate
the behavior, or not?
Many thanks in advance,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Oct 29, 2010 at 5:18 PM, Simone
Hi James,
IMHO the Read/Write lock stuff is a very cool idea, it rocks!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Oct 29, 2010 at 5:09 PM, James Carman
wrote:
> On Fri, Oct 29, 2010 at 10:58 AM, Gary Gregory
> wrote:
>>
>> I thought we said that pools sett
Hi Gary,
I have the same trouble, and that's why I wrote my previous email; in
the Stack(Keyed)ObjectPool(Factory) I implemented the Config class as
immutable, as discussed in a previous thread in the ML, so I had to
copy the data from the config to pool/factory to allow the mutability.
I fond it a
On Fri, Oct 29, 2010 at 10:58 AM, Gary Gregory
wrote:
>
> I thought we said that pools settings should be configurable. The current
> Config root class has setters.
>
> Are we saying that, yes, pools are configurable post-creation but not through
> config objects? Should config objects be cloned
On 2010-10-27, Max Birkoff wrote:
> I had approached the ant project with this request (as I had been
> using the tar under org.apache.tools.tar.TarEntry that ships with ant)
> but Stefan Bodewig directed me here.
Suggested this would be the better place 8-)
> If this patch is accepted,
I've co
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Friday, October 29, 2010 20:46
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> If the config objects are immutabl
> -Original Message-
> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
> Sent: Friday, October 29, 2010 20:34
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> Hi again Gary,
> the only thing I'm not sure about the patch - not blockin anywa
If the config objects are immutable, then you can store the reference.
On Fri, Oct 29, 2010 at 10:34 AM, Simone Tripodi
wrote:
> Hi again Gary,
> the only thing I'm not sure about the patch - not blockin anyway, it
> can be modified later - is that one of the discussed requirement was
> not stori
Hi again Gary,
the only thing I'm not sure about the patch - not blockin anyway, it
can be modified later - is that one of the discussed requirement was
not storing the config reference but rather copying the data.
BTW I like the design!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.9
Hi Gary,
well done, it seems to me it is a very good work, +1 on applying this patch!!!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Oct 29, 2010 at 3:55 PM, Gary Gregory
wrote:
> Hi All,
>
> I see now in trunk that GenericKeyedObjectPoolConfig
Hi All,
I see now in trunk that GenericKeyedObjectPoolConfig extends
GenericObjectPoolConfig, which I like.
It seems that the next step would be for GenericKeyedObjectPoolFactory and
GenericObjectPoolFactory to share a common superclass.
To see what I mean, look at the patch in
https://issues
> [...]
> >
> >In the above, there is also a hidden request: I would like to remove the
> >checked "FunctionEvaluationException" from the interface. As mentioned
> >recently in a [VFS] thread, the only argument in favor of checked
> >exceptions
> >is in situations where the code really implements l
--
From: "Gilles Sadowski"
Sent: Wednesday, October 27, 2010 3:46 AM
To:
Subject: [Math] Package for "UnivariateRealFunction"s
Hi.
What do you think of creating a "function" package that would contain all
the usual functions as classes impleme
23 matches
Mail list logo
