FYI, The serialization problem should be fixed in the Derby 10.1 release which should be out in the next few days hopefully.
John Jacek Laskowski <[EMAIL PROTECTED]> wrote on 15/07/2005 08:29:24 AM: > Hi, > > I've recently been looking into the issue of printing out > java.io.NotSerializableException's during executing itests: > > 13:51:16,780 FATAL [EjbRequestHandler] Invocation result object is not > serializable: org.apache.derby.impl.jdbc.EmbedSQLException > java.io.NotSerializableException: > org.apache.derby.impl.sql.compile.TableName > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) > at > java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224) > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) > at > java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) > at > java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) > at > org.openejb.client.EJBResponse.writeExternal(EJBResponse.java:176) > at > org.openejb.server.ejbd.EjbRequestHandler. > processRequest(EjbRequestHandler.java:260) > > or some other Derby SQLExceptions I don't have at the moment. > > They show up when itests are run in a clean test environment after > executing 'clean' goal or at the first time. They turned out to be > application exceptions thrown by DatabaseBean.executeQuery(String > statement). So, when a SQL statement finishes with an error (like DROP > TABLE address when the table doesn't exist), the exception is propagated > back to the client. Unfortunatelly these Derby exceptions are not > serializable that's being reported when running the itests. It's very > annoying and looks bad. > > According to EJB 2.1 spec (page 396): > > An application exception thrown by an enterprise bean instance should be > reported to the client precisely (i.e., the client gets the same exception) > > So, OpenEJB follows the rule and tries to send it back to the client, > but I wonder if a) we could change the executeQuery method so that > SQLExceptions aren't sent back, which I think would be highly desirable > as the method is a helper method and isn't tested but invoked or b) > leave it as it is. > > I'd also introduce a property which would tell OpenEJB whether or not > application exceptions are sent back to a client entirely or partially, > like a boolean property - openejb.sendStackTrace. > > Comments? > > Jacek >
