On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote:
On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
DBCP-143 talks about problem with propagation of SQLNestedException
to clients and the comment suggests a conversion to normal Java
nested exception when we switch to Java 1.4. Since w
[
https://issues.apache.org/jira/browse/DBCP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-143:
Fix Version/s: (was: 1.3)
1.4
SQLNestedException has been deprecated in 1.3
Can anyone else reproduce this failure?
-dain
On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote:
Failed build logs:
http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F
DBCP-143 talks about problem with propagation of SQLNestedException
to clients and the comment suggests a conversion to normal Java
nested exception when we switch to Java 1.4. Since we made the leap,
I did a bit of refactoring to remove this exception class. Basically
I replace:
new
[
https://issues.apache.org/jira/browse/DBCP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-143:
Attachment: DBCP-143.patch
This patch replaces:
new SQLNestedException(msg, e);
with
-235
Project: Commons Dbcp
Issue Type: Bug
Reporter: Dain Sundstrom
Fix For: 1.3
The accessToUnderlyingConnectionAllowed property ManageConnection disables the
getInnerMostDelegate method used by DelegatingConnection equals, hashCode, and
toString
On Jul 21, 2007, at 12:35 PM, Phil Steitz wrote:
Its not quite that bad now; but the returning orphans do not get
closed on return. What happens now is that the GOP throws
IllegalStateException when you try to return an object (or perform any
other operation) on a closed pool. We could include
[
https://issues.apache.org/jira/browse/DBCP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved DBCP-221.
-
Resolution: Fixed
Assignee: Dain Sundstrom
BasicDataSource.close() now permanently marks the
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote:
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
> On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
>
>> I would love to have a fix for DBCP-44; but that could wait on
[
https://issues.apache.org/jira/browse/DBCP-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved DBCP-207.
-
Resolution: Fixed
Committed a fix for this specific problem, and created a JIRA for converting
: Dain Sundstrom
Fix For: 1.3
All default values for connections (auto-commit, read-only, transaction
isolation, etc) should be non-primitive types, so it can be determined if they
were configured by the user. Only default values configured by the user should
be set on connections
[
https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved DBCP-225.
-
Resolution: Fixed
Sendingsrc/java/org/apache/commons/dbcp/PoolableConnectionFactory.java
[
https://issues.apache.org/jira/browse/DBCP-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved DBCP-150.
-
Resolution: Fixed
Sendingsrc/java/org/apache/commons/dbcp/BasicDataSource.java
Sending
[
https://issues.apache.org/jira/browse/DBCP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom resolved DBCP-217.
-
Resolution: Fixed
Fixed as part of DBCP-11.
> Closing of underlaying connection instead of
When issues are complete, do you close or resolve them? I have been
closing them, but just noticed that may are resolved.
Also, should I create a DBCP 1.4 and move the issues (like max time
limit for pooled objects) we aren't going to get to for 1.3 over.
-dain
---
[
https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-155.
---
Resolution: Won't Fix
> [dbcp] allow to set >= 6 parameters to do non
[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-152.
---
Resolution: Won't Fix
> [DBCP] add a socketFactory attribute to BasicDataSource (to a
[
https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-97.
--
Resolution: Fixed
Fixed some time ago.
> setAutoCommit(true) when returning connection to the p
[
https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-212.
---
Resolution: Fixed
Fixed some time ago.
> PoolingDataSource closes physical connecti
[
https://issues.apache.org/jira/browse/DBCP-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-102.
---
Resolution: Fixed
Fixed some time ago.
> [dbcp] setReadOnly & setAutoCommit called too man
[
https://issues.apache.org/jira/browse/DBCP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-194.
---
Resolution: Fixed
Fixed some time ago.
> BasicDataSource.setLogWriter should not do createDataSou
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote:
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
> On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
>
>> I would love to have a fix for DBCP-44; but that could wait on
On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote:
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
I think this will require a patch to pooling (documented in
DBCP-221). What are the plans for pooling? This is a tiny change so
we
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Are there any DBCP-1.3 release plans? Based on the JIRAs I think we
are close to being ready to release. Are there any items th
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514366
]
Dain Sundstrom commented on DBCP-44:
Ok one more comment before I get lunch My sample code above is bad. It
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514364
]
Dain Sundstrom commented on DBCP-44:
BTW it isn't the evictor thread that is problematic per say (it could
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514362
]
Dain Sundstrom commented on DBCP-44:
This will take experimentation, but off the top of my head, I'd do som
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
I would love to have a fix for DBCP-44; but that could wait on pool
1.4 if necessary (and Ipersonally see no way to fix it just within
dbcp. It would be great if I was wrong on that).
I
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-44:
---
Attachment: DBCP-44.patch
This is an architectural problem in commons-pool
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Are there any DBCP-1.3 release plans? Based on the JIRAs I think we
are close to being ready to release. Are there any items that are
planned but don't have JIRAs?
There are
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
Here are some open JIRAs I think we can close:
Fixed:
DBCP-194 BasicDataSource.setLogWriter should not do createDataSource
DBCP-102 setReadOnly & setAutoCommit called too many times
DBCP-97 setAutoCommit(true) when returning connection to the poo
[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514273
]
Dain Sundstrom commented on DBCP-152:
-
Ralf,
Security is a very important issue for me, so I'm not saying t
I think passivate() is called automatically when the connection is
put back in the pool (due to the _conn.close() call). I think there
are tests that check that the statements were closed when the
connection is closed.
Anyway, I don't think it is a big deal to call passivate twice. It
u
[
https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-225:
Attachment: DBCP-225.patch
This patch checks for null returned from connection factory and throws an
[
https://issues.apache.org/jira/browse/DBCP-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-150:
Attachment: DBCP-150.patch
Implementation, java doc and test case
> [dbcp] BasicDataSource : set
Are there any DBCP-1.3 release plans? Based on the JIRAs I think we
are close to being ready to release. Are there any items that are
planned but don't have JIRAs?
-dain
Here are some open JIRAs I think we can close:
Fixed:
DBCP-194 BasicDataSource.setLogWriter should not do createDataSou
The PerUserDataSource and SharedPoolDataSource use primitives for the
read only, transaction isolation and auto commit default values so
there is not way to see if the value was set in the configuration.
This means there is no way to allow the driver defaults to pass
through like in the P
[
https://issues.apache.org/jira/browse/DBCP-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-207:
Attachment: DBCP-207.patch
Already fixed for PoolingDataSource, but PerUserDataSource and
[
https://issues.apache.org/jira/browse/DBCP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-110:
Summary: [dbcp] DBCP removeAbandoned not working (was: [dbcp] Problem
reported at
[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514054
]
Dain Sundstrom commented on DBCP-152:
-
DBCP supports JDBC standard properties, so if mysql ssl can be configured
[
https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514053
]
Dain Sundstrom commented on DBCP-155:
-
DBCP has support for JDBC connection properties. The JSSE properties you
[
https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514044
]
Dain Sundstrom commented on DBCP-97:
Yes, this is correct. When auto commit is off, you have an open transaction
[
https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514039
]
Dain Sundstrom commented on DBCP-53:
I don't think this is a DBCP issue. My guess is your torque configurati
[
https://issues.apache.org/jira/browse/DBCP-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514033
]
Dain Sundstrom commented on DBCP-209:
-
I believe that Michael should be using either the SharedPoolDataSource or
should also be closed.
-dain
On Jul 17, 2007, at 9:39 PM, Phil Steitz wrote:
On 7/17/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217
where the Statement.getConnection() and ResultSet.getStatement()
return the wrong ob
[
https://issues.apache.org/jira/browse/DBCP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-11:
---
Attachment: back-pointers.patch
This patch assures that all all returned Statements, PreparedStatements
I believe the duplicate close fix also addresses these JIRAs:
DBCP-5 PoolGuardConnectionWrapper violates close() contract
DBCP-23 SQLException When PoolablePreparedStatement Already Closed
-dain
-
To unsubscribe, e-mail: [EMAIL
the logical connection is closed the statements and result sets
are not closed as required buy the spec.
-dain
On Jul 17, 2007, at 2:42 PM, Dain Sundstrom wrote:
I'm working on a fix for the back pointers bugs DBCP-11 and
DBCP-217 where the Statement.getConnection() and
ResultSet.g
I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217
where the Statement.getConnection() and ResultSet.getStatement()
return the wrong objects. The fix is pretty simple; we just need to
make sure we wrap Statements and ResultSets returned from
DelegatingConnection with the
[
https://issues.apache.org/jira/browse/DBCP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-233:
Attachment: CloseTwice.patch
> Allow connection, statement, and result set to be closed multi
Type: Improvement
Reporter: Dain Sundstrom
Fix For: 1.3
Attachments: CloseTwice.patch
This patch allows Connection, Statement, PreparedStatement, CallableStatement
and ResultSet to be closed multiple times. The first time close is called the
resource is closed and
On Jul 13, 2007, at 11:17 PM, Henri Yandell wrote:
On 7/13/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Dain Sundstrom wrote:
> Are snapshot jars for commons (specifically commons-dbcp) published
> anywhere? I expected to see them here
> http://people.apache.org/repo/m2-snap
Are snapshot jars for commons (specifically commons-dbcp) published
anywhere? I expected to see them here http://people.apache.org/repo/
m2-snapshot-repository/
-dain
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
Thanks for applying the patch and thanks for fixing my terrible
spelling :)
-dain
On Jul 13, 2007, at 6:25 AM, Phil Steitz wrote:
On 7/13/07, Julien Aymé <[EMAIL PROTECTED]> wrote:
It seems good; just a little mispelling problem with the protected
method createConectionFactory():
Wouldn't i
[
https://issues.apache.org/jira/browse/DBCP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-230:
Attachment: BasicManagedDataSource.patch
> [DBCP] BasicManagedDataSou
[DBCP] BasicManagedDataSource
-
Key: DBCP-230
URL: https://issues.apache.org/jira/browse/DBCP-230
Project: Commons Dbcp
Issue Type: New Feature
Reporter: Dain Sundstrom
Fix For: 1.3
On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote:
Thanks, Dain. I applied the patch.
I also patched the m1 and ant builds to work. The Ant now fails with
JDK 1.3, but unless someone screams loudly soon, we have moved the
minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so
this
[dbcp] Managed Connection support
-
Key: DBCP-228
URL: https://issues.apache.org/jira/browse/DBCP-228
Project: Commons Dbcp
Issue Type: New Feature
Reporter: Dain Sundstrom
Attachments
[
https://issues.apache.org/jira/browse/DBCP-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-228:
Attachment: ManagedConnection.patch
> [dbcp] Managed Connection supp
On May 13, 2004, at 8:39 PM, Mark R. Diggory wrote:
There is a convergence between the Gump Integration and this unstable
repository which I hope is occurring, eventually, we hope that Gump
will be used to produce a nightly build repository for projects, and
that most projects will start taking
On May 13, 2004, at 5:44 PM, Noel J. Bergman wrote:
I understand the desire to not having projects use snapshots, but the
reality is you just sometimes need to build against head. The
geronimo
team tries to limit snapshots to projects that do instep releases with
geronimo but that is still about
On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote:
I am opposed to adding snapshots to ibiblio, as I have seen it create
isues.
IMHO ibiblio should be released/stable code only.
Can you be more clear? I think ibiblio snapshots are great and would
hate to see them go away. Think of all the
On May 5, 2004, at 2:20 PM, robert burrell donkin wrote:
On 4 May 2004, at 23:52, Simon Kitching wrote:
I don't understand why the Geronimo team are concerned about large jar
files considering they are building a server environment; nevertheless
it appears that they are. So I'm willing to give
t;Apache", but I believe it will work.
-dain
/*
* Dain Sundstrom
* Partner
* Core Developers Network
*/
On May 3, 2004, at 2:11 AM, robert burrell donkin wrote:
i definitely agree that one jar is the best solution for many users.
for those users for wh
On Apr 22, 2004, at 2:40 PM, Michael Heuer wrote:
Perhaps some of the classes in [collections] could be presented as a
JSR
for inclusion in the JDK at some later date. That might cut the size
of
the jar some. :)
All kidding aside, I like this idea. How about starting by splitting
collections
On Apr 12, 2004, at 3:43 PM, Mladen Turk wrote:
From a chat with the Geronimo team today: "The Geronimo
contains an IOC
(dependency injection) micro-kernel which provides only basic
wiring of services and life cycle management.
Are the guys willing to pull that out,
No, but it is isolated and will
66 matches
Mail list logo
