Jeff Martin (Migrated from SEC-1709) said:
Similar to SEC-338, org.springframework.security.authentication.AbstractAuthenticationToken does not define a serialVersionUID. This is causing failures in our development environment because we pass an authentication token around in RMI (thus the serialization). The exception is:
2011-03-26 13:29:11,278 ERROR STDERR Caused by: org.springframework.remoting.RemoteAccessException: Could not access remote service [rmi://x.x.x.x:x/RmiAdapter]; nested exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.io.InvalidClassException: org.springframework.security.authentication.AbstractAuthenticationToken; local class incompatible: stream classdesc serialVersionUID = -3194696462184782834, local class serialVersionUID = 1043617290326266361
Please add a serialVersionUID to AbstractAuthenticationToken and it's subclasses. Or, since this has come up before in other classes (SEC-338, etc), add serialVersionUID's to all serializable classes. It's an Eclipse compile option that we require for all of our code.
Luke Taylor said:
This isn't a major bug, as it has been a deliberate policy to avoid making any guarantee of compatibility of serialized classes between versions. Serialization is a bit of a minefield and a maintenance headache, so we have avoided attempting to maintain a serializability contract between versions.
I would recommend that you use the same Spring Security version on both client and server, and it may also be a good idea to customize the Authentication object used and implement readObject and writeObject explicitly. This may also allow you to produce a more compact representation which would be preferable for use in client/server applications.
Jeff Martin said:
I should have mentioned it but we are using the same Spring Security version on the client and the server. The difference (for us) is that even minor releases of the JDK affect how the serialVersionUID is calculated if not explicitly specified (Sun/Oracle Java 6.0.16 and 6.0.23 in this case).
Hmm. That is a pain. I would have expected the JVM algorithm to be the same. In fact it sounds like a VM bug. Given that's the situation, we should probably conside adding a fixed ID, even though we will still explicitly require that the same Spring Security version is used.
I've added a fixed static value to the SpringSecurityCoreVersion which is now used as the serializationVersionUID values for security context, authentication tokens and related classes.
Commit log was accidentally labelled as SEC-1700.