Re: renaming jar files
On Sun, Mar 23, 2008 at 6:29 AM, Mark Thomas [EMAIL PROTECTED] wrote: Costin Manolache wrote: I understand people using JDBC authenticator would miss the connection pooling - but maybe they could download it separately ? Would't be easier to just download the 'official' version ? No. commons-dbcp supports far more than just pooling for the JDBC authenticator. The reason we do the renaming is to avoid class loading issues when users want to use a Tomcat-managed connection pool alongside an application that uses commons-dbcp and/or commons-pool directly. I'm also curious, assuming JDK1.5 is used to compile - would the tomcat distro work in JDK1.6 if dbcp is compiled with 1.5 ? Yes it does. To be more accurate, I haven't seen any issues using the re-packaged DBCP on 1.6. In any case - it kind of sucks to not be able to build following the instructions ( ant download, ant ) - I didn't find any ref that JDK1.6 is not supported for build. Correct. If you want to fix this you could always port the DBCP build fixes from commons. This isssue is being tracked as DBCP-191. Comments, suggestions, patches are welcome on the ticket or on commons-dev. Opinions on JDK support levels/branching from tomcat perspective would be appreciated. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 5.5.28 released
Filip Hanik - Dev Lists wrote: The Apache Tomcat team announces (a bit late) the immediate availability of Apache Tomcat 5.5.28 stable. Apache Tomcat 5.5.28 incorporates numerous security updates and bug fixes. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html The updated changelog showing .28 changes needs to be pushed to the website. Looks like the updates have been made in svn, just not published yet. Phil Downloads: http://tomcat.apache.org/download-55.cgi Thank you, The Tomcat Team - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1039707 - in /tomcat/trunk: java/org/apache/catalina/session/ManagerBase.java webapps/docs/config/manager.xml
With this change to createRandom it is not clear to me what the value of the
reseeding is when the SecureRandom is not user-supplied. Maybe a crypto
expert can comment. It would speed up initialization in the default case if
the reseeding was only done for user-defined generators. Alternatively, you
could remove it altogether and doc the fact that user-supplied classes are
expected to be self-seeding.
Phil
On Sat, Nov 27, 2010 at 12:05 PM, ma...@apache.org wrote:
Author: markt
Date: Sat Nov 27 17:05:27 2010
New Revision: 1039707
URL: http://svn.apache.org/viewvc?rev=1039707view=rev
Log:
Make SecureRandom the fall-back and use SecureRandom throughout rather than
Random
Modified:
tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java
tomcat/trunk/webapps/docs/config/manager.xml
Modified: tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java?rev=1039707r1=1039706r2=1039707view=diff
==
--- tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java Sat Nov
27 17:05:27 2010
@@ -41,7 +41,6 @@ import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import java.util.Queue;
-import java.util.Random;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.atomic.AtomicLong;
@@ -128,7 +127,8 @@ public abstract class ManagerBase extend
* designed this way since random number generator use a sync to make
them
* thread-safe and the sync makes using a a single object slow(er).
*/
-protected QueueRandom randoms = new ConcurrentLinkedQueueRandom();
+protected QueueSecureRandom randoms =
+new ConcurrentLinkedQueueSecureRandom();
/**
* Random number generator used to see @{link {...@link #randoms}.
@@ -136,9 +136,9 @@ public abstract class ManagerBase extend
protected SecureRandom randomSeed = null;
/**
- * The Java class name of the random number generator class to be used
- * when generating session identifiers. The random number generator(s)
will
- * always be seeded from a SecureRandom instance.
+ * The Java class name of the secure random number generator class to
be
+ * used when generating session identifiers. The random number
generator(s)
+ * will always be seeded from a SecureRandom instance.
*/
protected String randomClass = java.security.SecureRandom;
@@ -505,23 +505,23 @@ public abstract class ManagerBase extend
* Create a new random number generator instance we should use for
* generating session identifiers.
*/
-protected Random createRandom() {
+protected SecureRandom createRandom() {
if (randomSeed == null) {
createRandomSeed();
}
-Random result = null;
+SecureRandom result = null;
long t1 = System.currentTimeMillis();
try {
// Construct and seed a new random number generator
Class? clazz = Class.forName(randomClass);
-result = (Random) clazz.newInstance();
+result = (SecureRandom) clazz.newInstance();
} catch (Exception e) {
-// Fall back to the simple case
+// Fall back to the default case
log.error(sm.getString(managerBase.random,
randomClass), e);
-result = new java.util.Random();
+result = new java.security.SecureRandom();
}
byte[] seedBytes = randomSeed.generateSeed(64);
ByteArrayInputStream bais = new ByteArrayInputStream(seedBytes);
@@ -966,7 +966,7 @@ public abstract class ManagerBase extend
}
closeRandomInputStreams();
}
-Random random = randoms.poll();
+SecureRandom random = randoms.poll();
if (random == null) {
random = createRandom();
}
Modified: tomcat/trunk/webapps/docs/config/manager.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/manager.xml?rev=1039707r1=1039706r2=1039707view=diff
==
--- tomcat/trunk/webapps/docs/config/manager.xml (original)
+++ tomcat/trunk/webapps/docs/config/manager.xml Sat Nov 27 17:05:27 2010
@@ -134,8 +134,9 @@
/attribute
attribute name=randomClass required=false
-pJava class name of the codejava.util.Random/code
-implementation class to use. If not specified, the default value
is
+pName of the Java class that extends
+codejava.security.SecureRandom/code to use to generate session
IDs.
+If not specified, the default value is
Re: svn commit: r1039707 - in /tomcat/trunk: java/org/apache/catalina/session/ManagerBase.java webapps/docs/config/manager.xml
On Sun, Nov 28, 2010 at 8:37 AM, Mark Thomas ma...@apache.org wrote: On 27/11/2010 21:01, Phil Steitz wrote: With this change to createRandom it is not clear to me what the value of the reseeding is when the SecureRandom is not user-supplied. Maybe not a huge amount. It would speed up initialization in the default case if the reseeding was only done for user-defined generators. Alternatively, you could remove it altogether and doc the fact that user-supplied classes are expected to be self-seeding. That makes sense but my focus right now isn't on performance at initialisation but performance of session ID generation. I want to get to the bottom of why SecureRandom on OSX was behaving as if it was synchronized internally even though I didn't see any blocking in YourKit. More importantly, does it behave the same way on Linux? More testing is required. OK, sorry for the noise. I may be wrong, but I think the default on Linux at least used to be NativePRNG. Looking at the source for NativePRNG (e.g., [1]), it appears that it mixes entropy bytes from /dev/urandom on each call to engineNextBytes - not just at initialization, which could cause periodic waits on /dev/urandom. See [2] for more info. [1] h*ttp://s.apache.org/5KC http://s.apache.org/5KC* [2] http://s.apache.org/SRg Phil
Re: Publishing process for JARs for Maven Central
On 12/16/11 12:56 PM, Mark Thomas wrote: All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I would be very interested to know if anyone has figured out a way to fully script Nexus. AFAIK, Nexus requires that you use the GUI and also (sic) store credentials in a plaintext file. Maybe someone has figured out a way around this. I would be very interested to learn this so we can improve the not-quite-functional process that we have been fumbling with in Commons [1]. FWIW, my NSHO is that if you have a working script that produces good artifacts that can be scpd to central, there is no reason to bring in proprietary software, plaintext credential files or GUI steps. Phil [1] http://wiki.apache.org/commons/UsingNexus I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On Dec 17, 2011, at 6:44 AM, sebb seb...@gmail.com wrote: On 17 December 2011 05:19, Phil Steitz phil.ste...@gmail.com wrote: On 12/16/11 12:56 PM, Mark Thomas wrote: All, There are currently two options for publishing JARs to Maven Central: 1. scp+rsync via people.a.o 2. Nexus Personally, my only requirements are: a) that the JARs reach Maven Central b) publishing is as simple as running a single script I would be very interested to know if anyone has figured out a way to fully script Nexus. AFAIK, Nexus requires that you use the GUI I think that's the main advantage or Nexus - makes it difficult to accidentally release files. This happened at least once in Commons before we started using Nexus. Only via the release plugin and not following the documented process at the time. Adding GUI steps and more mysterious software *decreases* control. AIUI there is a REST interface which could be scripted if one could find the docs. But I think it would negate one of the main benefits if this allowed releases to be published to Maven Central automatically. Which the simple rsync setup that tomcat and some Commons holdouts still use does in a much simpler and more transparent way. and also (sic) store credentials in a plaintext file. Maybe someone AFAIK that's not true - or at least if it is, that's due to using Maven deploy, rather than Nexus, which is not directly involved in the upload. has figured out a way around this. I would be very interested to You can store the master password on a USB stick for Maven to use. Or you could use something like a TrueCrypt container file. Thats what I meant above. Phil learn this so we can improve the not-quite-functional process that we have been fumbling with in Commons [1]. FWIW, my NSHO is that if you have a working script that produces good artifacts that can be scpd to central, there is no reason to bring in proprietary software, plaintext credential files or GUI steps. Phil [1] http://wiki.apache.org/commons/UsingNexus I don't particularly care about the details. As long as all I have to do is run a script and the JARs end up in Maven Central I'm happy. I know option 1 works and I assume 2 will work the same way. Therefore I have no preference for either approach. Does anyone else have any requirements / views that would suggest one approach is better than the other? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
On 12/17/11 11:42 AM, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:35, Antonio Petrelli wrote: 2011/12/17 Mark Thomas ma...@apache.org On 17/12/2011 18:14, Antonio Petrelli wrote: Ok then interprete my words as: now you can use a staging repository. This way, artifacts may be tested *before* they are released. The scp+rsync process also has a staging repository (and using that did not cause any meta-data issues). The JARs are the standard Tomcat JARs. The Maven release process just adds the metadata files and moves the JARs + metadata around. Since the JARs are already tested as part of the Tomcat release process, we never had a need to use the staging repository and I don't see that changing. There is also a snapshot repository and we did use that early on in the Tomcat 7 development process (before the first release) mainly because one user who was doing a lot of testing was using Maven and the snapshot repository was the easiest way to get them the latest build. We stopped using the snapshot repository some time ago. I can't remember if it was after the first release or after the first stable release. Ok then using Nexus makes sense only if you are going to use Maven for all the release process (it's a matter of two commands and a Nexus stage promotion). I think that now you should change the subject into: why should you switch to pure Maven build process? :-D (Joking, but not too much) Yeah, that isn't going to happen :) I've seen way to much pain and grief with Maven on the Commons list to ever want to even think about converting the Tomcat build process to Maven. Commons? That's strange, they are only libraries. Probably they never had cringe-mode-off / a Maven wizard like me cringe-mode-on /. We have several maven committers on the PMC and have been using maven since the 1.x days. One thing we have learned is that maven builds require regular care and feeding. We are on version 23 of the Commons Parent pom. One statistic that I have often thought would be interesting to look at is how much time (maybe proxied by number of metadata commits) is spent maintaining maven vs Ant builds. I wonder if on net maven saves time? The tomcat Ant build has been relatively stable compared to the maven projects I know. Could be I am wrong, but I bet tomcat has overall spent less time fussing with its build than the average ASF maven project. In Commons, our success getting to periods of stability (we are between stable points now) has depended on having multiple deeply maven-knowledgeable people prepared to do the work to keep component builds up to date with maven, ASF/Sonatype infrastructure and plugin changes. If there are several tomcat committers willing to step up to do this, then I am sure you can get it to work. Otherwise, you are likely better off staying with Ant. Phil Seriously, if I have the time, I could fork Tomcat 7 from GitHub to try if I can change this situation. I already did it for Velocity (using SVN). The only difficulty is the website. Antonio - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7, DBCP 1.x and generics
> On Mar 18, 2019, at 1:28 PM, Mark Thomas wrote: > > All, > > I started to work on cleaning up the DBCP generics warnings in 7.0.x before I > remembered what "fun" it was when I did this for DBCP2. While some of it is > straight-forward, some of it requires some refactoring. From memory, the > refactoring did fix a few bugs along the way. > > Given that the changes aren't trivial, I wanted to get some feedback from the > community as to the best approach here. Options include: > > a) No nothing > > b) Fix the trivial generics > > c) Fix all the generics including any necessary refactoring > > d) Something else IIRC, there was a 1.6 release that was really nothing but generics fixes over 1.5.7. You might try just pulling those sources in. Phil > > > Thoughts? > > mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist
On 10/16/19 7:55 AM, Mark Thomas wrote:
On 12/10/2019 00:03, Phil Steitz wrote:
How about adding the DBCP unit tests to the source tree? I suspect some
would have failed due to this change. If others think this is a good
idea, I could take a stab at genericising them and creating a PR to add
them.
+1
I'd suggest several commits. Something like:
- Copy latest 1.x from Commons
- Fix package naming issues
- Fix any running issues
- Fix warnings (inc. generics)
That way it should be easy to trace what changed from Commons and why.
The exact detail of how the changes are split between commits is not
important. It is the easy traceability that matters.
I just submitted a PR with the BasicDataSource tests and its
dependencies with commits in the order above. I disabled tests that
were failing due to this issue (BZ 63833). If this looks OK, I will
continue to add the rest of them. I can also do a separate PR to fix BZ
63833 and re-enable the failing tests. I could not find a 1.6 JDK to
test with, so my testing was with 1.7 and 1.8 using test.name to limit
execution to the tests that I was adding.
Phil
Mark
On 10/11/19 3:31 PM, bugzi...@apache.org wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63833
Phil Steitz changed:
What |Removed |Added
OS| |All
--- Comment #2 from Phil Steitz ---
This is a regression from the generics conversion in
PoolableConnectionFactory.
The original DBCP 1.x code effectively null-checked the object to be
destroyed:
public void destroyObject(Object obj) throws Exception {
if(obj instanceof PoolableConnection) {
((PoolableConnection)obj).reallyClose();
}
Removing the instanceOf check makes NPE possible:
public void destroyObject(PoolableConnection obj) throws Exception {
obj.reallyClose();
}
Solution is to add an explicit null check in destroyObject.
Similar changes should be made to activate, passivate, validate methods.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist
On 10/16/19 7:55 AM, Mark Thomas wrote:
On 12/10/2019 00:03, Phil Steitz wrote:
How about adding the DBCP unit tests to the source tree? I suspect some
would have failed due to this change. If others think this is a good
idea, I could take a stab at genericising them and creating a PR to add
them.
+1
I'd suggest several commits. Something like:
- Copy latest 1.x from Commons
- Fix package naming issues
- Fix any running issues
- Fix warnings (inc. generics)
That way it should be easy to trace what changed from Commons and why.
The exact detail of how the changes are split between commits is not
important. It is the easy traceability that matters.
Got it. I have started working on this. I will likely submit PRs that
bundle commits in the sequence above for one or more test classes at a
time.
Phil
Mark
On 10/11/19 3:31 PM, bugzi...@apache.org wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63833
Phil Steitz changed:
What |Removed |Added
OS| |All
--- Comment #2 from Phil Steitz ---
This is a regression from the generics conversion in
PoolableConnectionFactory.
The original DBCP 1.x code effectively null-checked the object to be
destroyed:
public void destroyObject(Object obj) throws Exception {
if(obj instanceof PoolableConnection) {
((PoolableConnection)obj).reallyClose();
}
Removing the instanceOf check makes NPE possible:
public void destroyObject(PoolableConnection obj) throws Exception {
obj.reallyClose();
}
Solution is to add an explicit null check in destroyObject.
Similar changes should be made to activate, passivate, validate methods.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/03: Fix warnings with Java 6 caused by missing @Override annotations
Sorry I missed all of these things. Is there a checkstyle or eclipse
config somewhere that I can use to make sure the next batch is clean?
Phil
On 10/25/19 11:12 AM, ma...@apache.org wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 9e612f96ecfd96e3e96f2ea95ce9500d03f96691
Author: Mark Thomas
AuthorDate: Fri Oct 25 13:13:06 2019 +0200
Fix warnings with Java 6 caused by missing @Override annotations
---
.../dbcp/dbcp/AbstractConnectionPoolTest.java | 90 +-
.../tomcat/dbcp/dbcp/TestBasicDataSource.java | 112 ++--
.../tomcat/dbcp/dbcp/TesterCallableStatement.java | 111
.../apache/tomcat/dbcp/dbcp/TesterConnection.java | 49 ++
.../tomcat/dbcp/dbcp/TesterDatabaseMetaData.java | 174 +++
test/org/apache/tomcat/dbcp/dbcp/TesterDriver.java | 6 +
.../tomcat/dbcp/dbcp/TesterPreparedStatement.java | 74 +++-
.../apache/tomcat/dbcp/dbcp/TesterResultSet.java | 191 -
.../apache/tomcat/dbcp/dbcp/TesterStatement.java | 42 +
9 files changed, 747 insertions(+), 102 deletions(-)
diff --git a/test/org/apache/tomcat/dbcp/dbcp/AbstractConnectionPoolTest.java
b/test/org/apache/tomcat/dbcp/dbcp/AbstractConnectionPoolTest.java
index 758f4e5..7a5db76 100644
--- a/test/org/apache/tomcat/dbcp/dbcp/AbstractConnectionPoolTest.java
+++ b/test/org/apache/tomcat/dbcp/dbcp/AbstractConnectionPoolTest.java
@@ -5,9 +5,9 @@
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -35,7 +35,7 @@ import junit.framework.TestCase;
/**
* Base test suite for DBCP pools.
- *
+ *
* @author Rodney Waldhoff
* @author Sean C. Sullivan
* @author John McNally
@@ -47,6 +47,7 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
super(testName);
}
+@Override
public void tearDown() throws Exception {
super.tearDown();
// Close any connections opened by the test
@@ -54,7 +55,7 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
Connection conn = (Connection) connections.pop();
try {
conn.close();
-} catch (Exception ex) {
+} catch (Exception ex) {
// ignore
} finally {
conn = null;
@@ -63,18 +64,18 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
}
protected abstract Connection getConnection() throws Exception;
-
+
protected int getMaxActive() {
return 10;
}
-
+
protected long getMaxWait() {
return 100L;
}
-
+
/** Connections opened during the course of a test */
protected Stack connections = new Stack();
-
+
/** Acquire a connection and push it onto the connections stack */
protected Connection newConnection() throws Exception {
Connection connection = getConnection();
@@ -82,7 +83,7 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
return connection;
}
-// --- Utility Methods -
+// --- Utility Methods -
protected String getUsername(Connection conn) throws SQLException {
Statement stmt = conn.createStatement();
@@ -93,14 +94,14 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
return null;
}
-// --- tests -
+// --- tests -
public void testClearWarnings() throws Exception {
Connection[] c = new Connection[getMaxActive()];
for (int i = 0; i < c.length; i++) {
c[i] = newConnection();
assertTrue(c[i] != null);
-
+
// generate SQLWarning on connection
c[i].prepareCall("warning");
}
@@ -112,10 +113,10 @@ public abstract class AbstractConnectionPoolTest extends
TestCase {
for (int i = 0; i < c.length; i++) {
c[i].close();
}
-
+
for (int i = 0; i < c.length; i++) {
c[i] = newConnection();
-}
+}
for (int i = 0; i < c.length; i++) {
// warnings should have been cleared by putting the connection
back in the pool
@@ -390,7 +391,7 @@ public abstract class
Re: [Bug 63833] NPE in DBCP when attempting to connect to a database that doesn't exist
How about adding the DBCP unit tests to the source tree? I suspect some
would have failed due to this change. If others think this is a good
idea, I could take a stab at genericising them and creating a PR to add
them.
On 10/11/19 3:31 PM, bugzi...@apache.org wrote:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63833
Phil Steitz changed:
What|Removed |Added
OS||All
--- Comment #2 from Phil Steitz ---
This is a regression from the generics conversion in PoolableConnectionFactory.
The original DBCP 1.x code effectively null-checked the object to be destroyed:
public void destroyObject(Object obj) throws Exception {
if(obj instanceof PoolableConnection) {
((PoolableConnection)obj).reallyClose();
}
Removing the instanceOf check makes NPE possible:
public void destroyObject(PoolableConnection obj) throws Exception {
obj.reallyClose();
}
Solution is to add an explicit null check in destroyObject.
Similar changes should be made to activate, passivate, validate methods.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
