I've written up a JIRA for the serialization/deserialization related stuff:
http://jira.codehaus.org/browse/OPENEJB-47 More below on the other stuff.... On Fri, Jul 15, 2005 at 10:34:51AM +0200, Jacek Laskowski wrote: > David Blevins wrote: > > > >If I remember from the test case uses SQLException as an application > >exception. > > 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. > >I don't think we really need a flag for something like this as I can't > >imagine a scenario where people would want the behavior we have now if > >there was something better. > > Well, the scenario would be when a deployer have to deal with exceptions > , which are of no value to the client, but are thrown by EJBs and aren't > serializable. I think it has a tremendous impact on the performance > where the unnecessary exceptions (that cause the > NoSerializableExceptions) are sent back to a client which in fact > disregards them. How to avoid sending them? 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? 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. -David
