On Apr 23, 2011, at 18:43, Phil Steitz wrote:
> On 4/23/11 2:24 PM, Gary Gregory wrote:
>> I'd like to think this reset should let us get to see a release with
>> generics sooner rather than later. I'm all for releasing early for
>> generics and moving on from three.
> We need to make whatever ot
On 4/23/11 2:24 PM, Gary Gregory wrote:
> I'd like to think this reset should let us get to see a release with
> generics sooner rather than later. I'm all for releasing early for
> generics and moving on from three.
We need to make whatever other API changes we are going to make for
the foreseeabl
Hi Gary,
my strong +1 on this, that's way we agreed on resetting the trunk (and
I started working to restore generics :P)
Thanks for your feedback!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 11:24 PM, Gary Gregory wrote:
> I'd like to think t
I'd like to think this reset should let us get to see a release with
generics sooner rather than later. I'm all for releasing early for
generics and moving on from three.
Gary
On Apr 23, 2011, at 12:14, Phil Steitz wrote:
> On 4/23/11 8:07 AM, Simone Tripodi wrote:
>> GREAT, thanks Phil!!!
>> I
On 4/23/11 10:08 AM, Simone Tripodi wrote:
> Hi Phil,
> I deduce to overlook, for now, also methods marked as @deprecated,
> (typically the setFactory() methods), right?
> Thanks in advance!
> Simo
>
Fine by me.
Phil
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sa
Hi Phil,
I deduce to overlook, for now, also methods marked as @deprecated,
(typically the setFactory() methods), right?
Thanks in advance!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 6:14 PM, Phil Steitz wrote:
> On 4/23/11 8:07 AM, Simone Trip
On 4/23/11 8:07 AM, Simone Tripodi wrote:
> GREAT, thanks Phil!!!
> I'm going to checkout the current trunk and updating pool code!!!
> Have a nice weekend!!!
> Simo
Great! Remember to update changes.xml in trunk with references to
issues as you bring things over. For now, let's just make the
ge
GREAT, thanks Phil!!!
I'm going to checkout the current trunk and updating pool code!!!
Have a nice weekend!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Apr 23, 2011 at 5:04 PM, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
>> On 22/03/2011 17:
On 3/22/11 11:20 AM, Mark Thomas wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
>> Hi Mark and all:
>>
>> It's good to hear someone is thinking about moving forward!
>>
>> pool2 trunk seems to me to be highly volatile based on having worked some in
>> pool2.
>>
>> I've read opinions here going b
On 23/03/2011 11:00, Simone Tripodi wrote:
> Thanks a lot Mark, much more than appreciated :)
> I'm +1 to support your idea of moving the current pool2 code in a
> branch, then continue the 1.5.5 work. The useful part that IMHO can be
> backported are the use of generics, replacing primitive consta
Thanks a lot Mark, much more than appreciated :)
I'm +1 to support your idea of moving the current pool2 code in a
branch, then continue the 1.5.5 work. The useful part that IMHO can be
backported are the use of generics, replacing primitive constants with
enumerations, removing some useless wrappe
On 23/03/2011 08:33, Simone Tripodi wrote:
> Hi all,
> sorry to join late the conversation but looks like living in a
> different timezone *is* an issue :(
No need to apologise. I wasn't going to go ahead until you had a chance
to give your feedback.
> I am the person "physically" responsable of
Hi all,
sorry to join late the conversation but looks like living in a
different timezone *is* an issue :(
I am the person "physically" responsable of the pool2 "big
refactoring" and I would be very sorry to see all that work dropped or
be useless; if you follow the old pool2 discussion in this ML
On 22/03/2011 18:52, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
> I don't
>> mind working with a moving target as long as it is moving towards a
>> clear goal. That goal for me is:
>> - Java 5 / generics
>> - fixing inconsistencies / oddities
>> - improved performance on DBCP in
On 22/03/2011 18:4, Gary Gregory wrote:
> On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas wrote:
>
>> What do folks think to the following:
>> - move pool trunk to a POOL_FUTURE branch
>> - restore pool trunk to a copy of the POOL_1_X branch
>> - rename pool package to o.a.c.pool2
>> (in reality th
On Tue, Mar 22, 2011 at 2:52 PM, Phil Steitz wrote:
> On 3/22/11 11:20 AM, Mark Thomas wrote:
> > On 22/03/2011 17:58, Gary Gregory wrote:
> >> Hi Mark and all:
> >>
> >> It's good to hear someone is thinking about moving forward!
> >>
> >> pool2 trunk seems to me to be highly volatile based on h
On 3/22/11 11:20 AM, Mark Thomas wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
>> Hi Mark and all:
>>
>> It's good to hear someone is thinking about moving forward!
>>
>> pool2 trunk seems to me to be highly volatile based on having worked some in
>> pool2.
>>
>> I've read opinions here going b
On Tue, Mar 22, 2011 at 2:20 PM, Mark Thomas wrote:
> On 22/03/2011 17:58, Gary Gregory wrote:
> > Hi Mark and all:
> >
> > It's good to hear someone is thinking about moving forward!
> >
> > pool2 trunk seems to me to be highly volatile based on having worked some
> in
> > pool2.
> >
> > I've re
On 22/03/2011 17:58, Gary Gregory wrote:
> Hi Mark and all:
>
> It's good to hear someone is thinking about moving forward!
>
> pool2 trunk seems to me to be highly volatile based on having worked some in
> pool2.
>
> I've read opinions here going back and forth as to how to solidify the API
> o
Hi Mark and all:
It's good to hear someone is thinking about moving forward!
pool2 trunk seems to me to be highly volatile based on having worked some in
pool2.
I've read opinions here going back and forth as to how to solidify the API
or even go /back/ to the pool1 style before moving forward a
Don't let the title get your hopes up. I don't have one yet, at least
not a complete one.
One of the primary driver for pool2 was to make use of
java.util.concurrent for the pool implementation and significantly
improve DBCP performance on multi-core systems (re-using ideas where we
can from Tomcat
21 matches
Mail list logo
