://www.99soft.org/
On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory
wrote:
>> -Original Message-
>> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
>> Sent: Wednesday, December 01, 2010 08:51
>> To: Commons Developers List
>> Subject: Re: [pool] Pool
> -Original Message-
> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
> Sent: Wednesday, December 01, 2010 08:51
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> Hi Gary,
> yes, more people involved on defining th
s OK though. We all get busy. Time to come back and
>>> reflect.
>>>
>>> I am still looking for these goals:
>>> - Generics released ASAP. I would be OK for a earlier release just to get
>>> this out.
>>> - Better names for properties and meth
ed ASAP. I would be OK for a earlier release just to get
>> this out.
>> - Better names for properties and methods
>> - Refactor to remove duplication
>>
>> Gary
>>
>>> -----Original Message-----
>>> From: Simone Tripodi [mailto:simone.trip...
t;> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
>> Sent: Tuesday, November 30, 2010 09:33
>> To: Commons Developers List
>> Subject: Re: [pool] Pool config vs. factory hierarchies.
>>
>> Hi all guys,
>> sorry for resurrecting a zombie message, bu
s for properties and methods
- Refactor to remove duplication
Gary
> -Original Message-
> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
> Sent: Tuesday, November 30, 2010 09:33
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
Hi all guys,
sorry for resurrecting a zombie message, but I've been busy at work
and haven't had the chance to contribute at all.
I could re-start committing code according to the requirements
described by Phil, If it works for you, so other tasks like
JMX/autoconfigure can be unlocked, please let
On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
>>
>>
>> You restore the pool fields that used to hold the configuration setting
>> properties and leave the getters and setters (for the mutable ones) in
>> place.
>>
>> Phil
>>
>>
> so something like this?
>
> public class GOP extends
>
>
> You restore the pool fields that used to hold the configuration setting
> properties and leave the getters and setters (for the mutable ones) in
> place.
>
> Phil
>
>
so something like this?
public class GOP extends {
/**
* ref to immutable config reference, immutable config val
That makes sense. I'll provide uniqueness through a property on the
ObjectName (UUID) and discoverability though the domain name if a name is
provided (so it will be easily apparent in the management system). A
resultant ObjectName like:
domain=[optionalProvidedName||org.apache.commons.pool.poolT
On 11/3/10 11:09 AM, Steven Siebert wrote:
Hi Phil,
I caught up on the messages, and I agree with Gary as well. What can I do
to help at this point? I think the group decided to implement immutable
configuration classes...the pools would provide a reference in the
pools/factories and sync/r
On Wed, Nov 3, 2010 at 11:51 AM, Steven Siebert wrote:
> I considered this, but the problem would be finding/viewing the specific
> pool in the JMX management app (ie jconsole). A GUID gives us uniqueness,
> but it doesn't give us the descriptive name. This has to do with ObjectName
> given when
I considered this, but the problem would be finding/viewing the specific
pool in the JMX management app (ie jconsole). A GUID gives us uniqueness,
but it doesn't give us the descriptive name. This has to do with ObjectName
given when registering the MBean...
On Wed, Nov 3, 2010 at 11:12 AM, Jame
On Wed, Nov 3, 2010 at 11:09 AM, Steven Siebert wrote:
> Something I have been considering is the how to represent multiple pools in
> a JVM. I'm thinking we'll need to add an additional optional configuration
> value "poolName" (or something similar) so the MBean will be uniquely named
> and dis
Hi Phil,
> I caught up on the messages, and I agree with Gary as well. What can I do
>> to help at this point? I think the group decided to implement immutable
>> configuration classes...the pools would provide a reference in the
>> pools/factories and sync/reconfigure with the reconfigure()?
On 11/2/10 10:05 AM, Steven Siebert wrote:
Hey all,
Sorry I've been away from the discussion, I was stuck in a building with no
windows for the last week (quite literally) and had very little time to
breath. At ApacheCon now, so have a bit of time to hack.
I caught up on the messages, and I ag
Hey all,
Sorry I've been away from the discussion, I was stuck in a building with no
windows for the last week (quite literally) and had very little time to
breath. At ApacheCon now, so have a bit of time to hack.
I caught up on the messages, and I agree with Gary as well. What can I do
to help
Hi all, Phil,
thanks for the explanations, very appreciated, I join Gary on saying
that maybe my thoughts on Pool are based on incorrect assumptions.
Assembling thought from various email and this thread IMHO starts
being a little difficult, If we could resume all that thoughts in a
wiki page I can
On 10/31/10 9:47 PM, Mark Thomas wrote:
On 31/10/2010 21:36, Phil Steitz wrote:
A radical idea that I have been considering is to propose that we
dispense with keyed pools altogether. The DBCP need can be met without
them (see jdbc-pool)
Can it? I know there are some things that DBCP can do t
On 31/10/2010 21:36, Phil Steitz wrote:
> A radical idea that I have been considering is to propose that we
> dispense with keyed pools altogether. The DBCP need can be met without
> them (see jdbc-pool)
Can it? I know there are some things that DBCP can do that jdbc-pool
can't such as https://is
Re: [pool] Pool
config vs. factory hierarchies.
On 10/30/10 2:30 PM, Simone Tripodi wrote:
Hi Phil, the benefits of eliminating the member variables in
favor of storing pool config reference are IMHO in therms of
code maintainability and keep it as much simple as possible.
Maybe I am being dense
On 31/10/2010 03:55, Phil Steitz wrote:
> On 10/30/10 10:55 PM, Gary Gregory wrote:
>> It would be possible for example, that the GOP subclass GKOP as a
>> degenerate simple case where the GOP has one pool in a GKOP. That
>> seems radical, but it would eliminate a lot of apparent code
>> duplicatio
nday, October 31, 2010
>>>> 06:35 To: Commons Developers List Subject: Re: [pool] Pool
>>>> config vs. factory hierarchies.
>>>>
>>>> On 10/30/10 2:30 PM, Simone Tripodi wrote:
>>>>> Hi Phil, the benefits of eliminating the member va
On Oct 31, 2010, at 8:55, "Phil Steitz" wrote:
> On 10/30/10 10:55 PM, Gary Gregory wrote:
>>> -Original Message- From: Phil Steitz
>>> [mailto:phil.ste...@gmail.com] Sent: Sunday, October 31, 2010
>>> 06:35 To: Commons Developers List Subject
On 10/30/10 10:55 PM, Gary Gregory wrote:
-Original Message- From: Phil Steitz
[mailto:phil.ste...@gmail.com] Sent: Sunday, October 31, 2010
06:35 To: Commons Developers List Subject: Re: [pool] Pool
config vs. factory hierarchies.
On 10/30/10 2:30 PM, Simone Tripodi wrote:
Hi Phil
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Sunday, October 31, 2010 06:35
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> On 10/30/10 2:30 PM, Simone Tripodi wrote:
> > H
On 10/30/10 2:30 PM, Simone Tripodi wrote:
Hi Phil,
the benefits of eliminating the member variables in favor of storing
pool config reference are IMHO in therms of code maintainability and
keep it as much simple as possible.
Maybe I am being dense here, but I don't quite get that. The pool
h
On Sat, Oct 30, 2010 at 2:30 PM, Simone Tripodi
wrote:
>
> -1 on adding the reconfigure(Config) method, we discussed about adding
> it in another thread, so I added to see if there are benefits but I
> don't see any advantage.
>
So, how are you going to change the properties? Through the builder
Hi Phil,
the benefits of eliminating the member variables in favor of storing
pool config reference are IMHO in therms of code maintainability and
keep it as much simple as possible.
You can see the difference between the current
Stack(Keyed)ObjectPool(Factory) - which are implemented according yo
On 10/30/10 12:56 PM, Phil Steitz wrote:
On 10/29/10 2:41 PM, James Carman wrote:
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
rec
On 10/29/10 2:41 PM, James Carman wrote:
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
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.
>
>
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.
> -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, the
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
elopers List
>> Subject: Re: [pool] Pool config vs. factory hierarchies.
>>
>> If the config objects are immutable, then you can store the reference.
>
> I thought we said that pools settings should be configurable. The current
> Config root class has setters.
>
&
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
> -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.
>
> I
> -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
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
47 matches
Mail list logo
