We have now converted from DataAccessException to an unchecked mirror of NamingException (in SVN trunk). I guess the problem remains, since we still wrap the checked NamingExceptions.

From one user's point of view I still prefer Serializable Exceptions. Perhaps when checked exceptions are caught and re-thrown as a mirrored-unchecked a test for instanceof Serializable could be performed? . . . And when not serializable discard the exception for the message and stack-trace?

All exceptions should be able to serialize themselves, since Throwable implements Serializable. In order to pinpoint which Exception is causing this, we would need a stack trace from your remoting stuff.

Now I can see the problem. There are no restrictions on setResolvedObj of NamingException. This means resolvedObj can be non-serializable, and in that case the serialization fails. It seems to be a known problem. One proposed workaround is to have a custom writeObject method that writes a null resolvedObj if it can be determined that it is not serializable. It's not foolproof, since even if resolvedObj implements Serializable, some object in the object graph below it might not.

I have checked in a possible solution where I implemented a custom writeObject that temporarily nulls out the resolvedObj before serialization. See the unit test for it in org.springframework.ldap.NamingExceptionTest. Please confirm that it solves your problem.

Verified by Jasper.