On 03/07/2011 22:43, Phil Steitz wrote:
> On 7/3/11 12:32 PM, Mark Thomas wrote:
>> On 26/06/2011 01:05, Phil Steitz wrote:
>>> On 6/25/11 4:28 PM, Mark Thomas wrote:
On 17/06/2011 09:02, Mark Thomas wrote:
> On 17/06/2011 00:32, Gary Gregory wrote:
>> I think 2.0 is the opportunity to
On 7/3/11 12:32 PM, Mark Thomas wrote:
> On 26/06/2011 01:05, Phil Steitz wrote:
>> On 6/25/11 4:28 PM, Mark Thomas wrote:
>>> On 17/06/2011 09:02, Mark Thomas wrote:
On 17/06/2011 00:32, Gary Gregory wrote:
> I think 2.0 is the opportunity to do this right. Almost like we were
> desig
On 26/06/2011 01:05, Phil Steitz wrote:
> On 6/25/11 4:28 PM, Mark Thomas wrote:
>> On 17/06/2011 09:02, Mark Thomas wrote:
>>> On 17/06/2011 00:32, Gary Gregory wrote:
I think 2.0 is the opportunity to do this right. Almost like we were
designing this from scratch.
Making the f
On 6/25/11 4:28 PM, Mark Thomas wrote:
> On 17/06/2011 09:02, Mark Thomas wrote:
>> On 17/06/2011 00:32, Gary Gregory wrote:
>>> I think 2.0 is the opportunity to do this right. Almost like we were
>>> designing this from scratch.
>>>
>>> Making the factory an invariant of the pool sounds good.
>>>
On 17/06/2011 09:02, Mark Thomas wrote:
> On 17/06/2011 00:32, Gary Gregory wrote:
>> I think 2.0 is the opportunity to do this right. Almost like we were
>> designing this from scratch.
>>
>> Making the factory an invariant of the pool sounds good.
>>
>> Otoh If a setFactory method exists it shoul
On 17/06/2011 00:32, Gary Gregory wrote:
> I think 2.0 is the opportunity to do this right. Almost like we were
> designing this from scratch.
>
> Making the factory an invariant of the pool sounds good.
>
> Otoh If a setFactory method exists it should be implemented fully. The
> throw an excepti
I think 2.0 is the opportunity to do this right. Almost like we were
designing this from scratch.
Making the factory an invariant of the pool sounds good.
Otoh If a setFactory method exists it should be implemented fully. The
throw an exception impl is pretty "smelly".
Gary
On Jun 16, 2011, at
On 6/16/11 10:19 AM, Mark Thomas wrote:
> On 16/06/2011 17:32, sebb wrote:
>> On 16 June 2011 17:25, Phil Steitz wrote:
>>> Yesterday I fixed some [dbcp] "problems" caused by the new [pool]
>>> requirement that setFactory can only be called once. The quotes are
>>> because most of the problems we
On 16/06/2011 17:32, sebb wrote:
> On 16 June 2011 17:25, Phil Steitz wrote:
>> Yesterday I fixed some [dbcp] "problems" caused by the new [pool]
>> requirement that setFactory can only be called once. The quotes are
>> because most of the problems were redundant calls to setFactory.
>> The reaso
On 6/16/11 9:32 AM, sebb wrote:
> On 16 June 2011 17:25, Phil Steitz wrote:
>> Yesterday I fixed some [dbcp] "problems" caused by the new [pool]
>> requirement that setFactory can only be called once. The quotes are
>> because most of the problems were redundant calls to setFactory.
>> The reason
On 16 June 2011 17:25, Phil Steitz wrote:
> Yesterday I fixed some [dbcp] "problems" caused by the new [pool]
> requirement that setFactory can only be called once. The quotes are
> because most of the problems were redundant calls to setFactory.
> The reason that we left setFactory in [pool] is
Yesterday I fixed some [dbcp] "problems" caused by the new [pool]
requirement that setFactory can only be called once. The quotes are
because most of the problems were redundant calls to setFactory.
The reason that we left setFactory in [pool] is that [dbcp]'s
connection factory constructors call
12 matches
Mail list logo
