This is a GUI client / application server / database server application.
On the GUI client side, we see java.lang.ClassNotFoundException:
org.apache.commons.dbcp.SQLNestedException.
This happens when the database server is down, DBCP cannot connect to the
database, and throws a org.apache.commons.dbcp.SQLNestedException.
Our application server code sends the java.sql.SQLException it sees to the
client via RMI.
However, on the client, we have not provided commons-dbcp.jar.
And I don't think we should - DBCP is server code.
But, when the client does not have SQLNestedException's class file, the attempt
to de-serialize it results in the ClassNotFoundException we've been seeing.
Even old http://java.sun.com/j2se/1.3/docs/api/java/sql/SQLException.html
has
the facilities that SQLNestedExcepion offers: It is able to chain another
SQLException to itself. So while SQLNestedException clearly causes problems, I
don't understand what DBCP gains from it.
What would we loose if it were scratched?
Looking at the source, the only part of SQLNestedException used is the SQLNestedException(String,Throwable). However sometimes that latter argument is not a SQLException; which would be one reason not to use the setNextException message.
Another alternative would be to bring the minimum JDK up to 1.4 and switch to standard exception chaining.