I was not talking about toString() of users' persistent classes. It is about the internal mechanics of OpenJPA encodes/decodes a persistent identity with its type information. When an application does String xid = "123ABC"; X x = em.find(X.class, id);
Under certain conditions, OpenJPA internally constructs an "id" Object xid (that is not of type String) using the type info (i.e. X.class) and the stringfid id value (i.e the String value "123ABC"). xid encodes both the type and key value. And the xid instance is the key for any subsequent lookup in OpenJPA internal caches etc. For the reported case, the process that encodes X.class + "123ABC" into xid was confused to lose the type information of the actual class and replaced it with the superclass. Compatibility.UseStrictIdentityValue helped to resolve that confusion. ----- Pinaki -- View this message in context: http://openjpa.208410.n2.nabble.com/OpenJPA-confusing-classes-tp5094249p5099457.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
