[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-development
Subject:    Re: [openejb-dev] Application exceptions and Derby exceptions not being serializable
From:       David Blevins <david.blevins () visi ! com>
Date:       2005-08-10 0:36:14
Message-ID: 20050810003614.GA15053 () django
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]