I must admit, I'm having a hard time following the conversation. If there is something that you see needs fixing, I whole heartedly support you. Fix away. I'd only ask you not to touch the protocol.
The client code in the test suite that creates and drops tables is here: http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/AxionTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/DerbyTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/InstantDbTestDatabase.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/PostgreSqlTestDatabase.java More below... On Wed, Aug 10, 2005 at 01:11:18AM +0200, Jacek Laskowski wrote: > David Blevins wrote: > > >>Correct. Should it throw SQLExceptions which in my opinion are of no > >>value to a client? I think the bean itself should catch it and throw > >>your own designed application exception, but... > > > > > >We're not exactly talking about "a client" as in clients in general. > >The test suite client creates and drops the required tables in the > >JUnit setup and tearDown methods via an ejb that accepts SQL > >statements and throws SQLException. This is fine for out test suite > >app. > > That's not necessarily true. The client is the JUnit app in this case. > It's a remote client that looks up beans and invokes their ops. So, I > don't agree it's not a client. It's a client as others. > > >I guess I'm not sure how to implement that. How do we know in advance > >what exceptions are of no value to the client? > > That's what I was asking about. The bean provider should decide which > exceptions are of any value to a client and I don't see any value in > exceptions being sent back to the client. What exactly would the client > do? The only thing I can think of is to report it, i.e. printing it out > to the console. It leads to my question. Since we're the bean provider I > wonder what the reason was to (attempt to) send SQLExceptions back to > its client, i.e. the JUnit script? > > >Also, since all > >exceptions implement serializable, we don't know a particular > >exception instance isn't serializable till we try and serialize it > >and it fails. > > Well, what about the java.io.Serializable interface? Isn't it all we > want to find out whether a class is serializable or not? As I'm saying, all Exceptions do implement the java.io.Serializable interface. So we have no way of knowing if the exception instance is holding data which isn't serializable (like the exception Derby throws us) until we actually try and serialize it. > That's however another story. The real question refers to the bean that > throws SQLException and I don't understand why we[*] have decided to do so? > > [*] I've included myself to be polite ;) I was basically trying to find a way that the test suite could setup and tear down the db tables before and after the tests run--or redeploy everything to swap out databases. So I put the SQL in client code and made an EJB that did nothing but excecute JDBC statements. Then I made test setup code for InstantDB and PostgreSQL. I though I also did one for MySQL, but I don't see it anymore. Dain made one for Axion and I don't know who made the Derby one. We do the same thing for setting up and tearing down the server itself before and after tests run. We have: http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/CorbaTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/IvmTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/RemoteTestServer.java http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/itest/org/openejb/test/RiTestServer.java We have the ability to swap out the server and database we want to run the tests on by supplying different properties to the test suite client. In a perfect world, we would actually test against the full matrix: Server: Local, Database: Axion Server: Local, Database: Derby Server: Local, Database: PostgreSQL Server: Remote, Database: Axion Server: Remote, Database: Derby Server: Remote, Database: PostgreSQL Server: Corba, Database: Axion Server: Corba, Database: Derby Server: Corba, Database: PostgreSQL I had that going for a short while years ago but it was just too much infrastructure for me to keep running. It would be nice to get Oracle and MySQL in that list as well. In an even more perfect world we'd test against not just different Server and Database combinations, but JVM versions as well. Server: Local, Database: Axion, JVM: 1.3 Server: Local, Database: Axion, JVM: 1.4 Server: Local, Database: Axion, JVM: 1.5 Server: Local, Database: Derby, JVM: 1.3 Server: Local, Database: Derby, JVM: 1.4 Server: Local, Database: Derby, JVM: 1.5 Server: Local, Database: PostgreSQL, JVM: 1.3 Server: Local, Database: PostgreSQL, JVM: 1.4 Server: Local, Database: PostgreSQL, JVM: 1.5 Server: Remote, Database: Axion, JVM: 1.3 Server: Remote, Database: Axion, JVM: 1.4 Server: Remote, Database: Axion, JVM: 1.5 Server: Remote, Database: Derby, JVM: 1.3 Server: Remote, Database: Derby, JVM: 1.4 Server: Remote, Database: Derby, JVM: 1.5 Server: Remote, Database: PostgreSQL, JVM: 1.3 Server: Remote, Database: PostgreSQL, JVM: 1.4 Server: Remote, Database: PostgreSQL, JVM: 1.5 Server: Corba, Database: Axion, JVM: 1.3 Server: Corba, Database: Axion, JVM: 1.4 Server: Corba, Database: Axion, JVM: 1.5 Server: Corba, Database: Derby, JVM: 1.3 Server: Corba, Database: Derby, JVM: 1.4 Server: Corba, Database: Derby, JVM: 1.5 Server: Corba, Database: PostgreSQL, JVM: 1.3 Server: Corba, Database: PostgreSQL, JVM: 1.4 Server: Corba, Database: PostgreSQL, JVM: 1.5 If you add JVM vendors (Sun, IBM, Apple, BEA) to the list, the combinations goes up to like 109. Throw on OS implementations and you get an insane number of test runs to complete. Anyway, the only thing from stopping us from doing it is: 1) Someone with good admin skills (a good automator) and a few hours a week. 2) Hardware 3) Licenses for the OSs and Databases Hope that gives some insight. Nothing is perfect or set in stone, so improvement is always welcome. -David
