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]
[
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
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 we made
[
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 createDataSource
[
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 many times
[
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 connections
[
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 pool
[
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 allow SSL
thread
[
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-global SSL
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-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
[
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-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
: 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-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
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
pool
1.4 if necessary
[
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
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
-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
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
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 could
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
pool
1.4 if necessary
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
[
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 that I
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
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 two things
[
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 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:comment-tabpanel#action_12514362
]
Dain Sundstrom commented on DBCP-44:
This will take experimentation, but off the top of my head, I'd do somthing
[
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 have
[
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
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
[
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
[
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 configuration
[
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-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-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-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
[
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
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
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
[
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 : setter
[
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
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:
[
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
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 objects. The fix
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
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.getStatement() return the wrong
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
[
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 multiple
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-snapshot-repository
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 it
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
[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
[
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] BasicManagedDataSource
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
[
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 support
[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
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
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 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
On May 5, 2004, at 2:20 PM, robert burrell donkin wrote:
On 4 May 2004, at 23:52, Simon Kitching wrote:
snip
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
/*
* 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 whom jar size is a big issue, then i'd say
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
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
65 matches
Mail list logo
