commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Fri, 29 Oct 2010 15:13:07 GMT
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 little redundant and not easy to keep in sync in the case
of Generic(Keyed)ObjectPool(Factory), I already gave a try to refactor
the Generic* classes but I failed so I had to revert my local changes.
I find the current Generic* approach much more agile and adaptable.

So now we can compare on /trunk both approaches and I honestly think
we have to make a final decision on wich of the two fits better to our
needs; I'm open like always to suggestions, but we should find a
unique way to manage the configuration stuff.

Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Oct 29, 2010 at 4:58 PM, Gary Gregory
<GGregory@seagullsoftware.com> wrote:
>> -----Original Message-----
>> From: jcarman@carmanconsulting.com [mailto:jcarman@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 immutable, then you can store the reference.
>
> 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 when passed in a constructor then?
>
> Gary
>
>>
>> On Fri, Oct 29, 2010 at 10:34 AM, Simone Tripodi
>> <simone.tripodi@gmail.com> 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 storing the config reference but rather copying the data.
>> > BTW I like the design!!!
>> > Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://www.99soft.org/
>> >
>> >
>> >
>> > On Fri, Oct 29, 2010 at 4:28 PM, Simone Tripodi
>> > <simone.tripodi@gmail.com> wrote:
>> >> 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
>> >> <GGregory@seagullsoftware.com> wrote:
>> >>> 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.apache.org/jira/browse/POOL-177.
>> >>>
>> >>> Beyond that, the idea would be to pull up the factory ivar.
>> >>>
>> >>> Gary Gregory
>> >>> Senior Software Engineer
>> >>> Rocket Software
>> >>> 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA
>> >>> Tel: +1.404.760.1560
>> >>> Email: ggregory@seagullsoftware.com
>> >>> Web: seagull.rocketsoftware.com
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message