Details
-
Type:
New Feature
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.2
-
Component/s: None
-
Labels:None
Description
mapper that works with CGLib enhanced classes - it removes the CGLib signature and stores the classes with their original name. I'll upload a unit test in a short while.
Issue Links
- is superceded by
-
XSTR-239
Xstream fails to deserialize elements in a CGLIB based HashMap proxy
-
Activity
unit test
Show
Costin Leau
added a comment - unit test
Costin Leau
added a comment - unit test Through unit tests I've noticed that CGLib uses by default a different signature for JDK classes with an exception for java.lang.Object.
See: http://cglib.sourceforge.net/xref/net/sf/cglib/core/DefaultNamingPolicy.html. The mapper doesn't take into account this naming convention (I've used only classes outside the JDK).
Show
Costin Leau
added a comment - Through unit tests I've noticed that CGLib uses by default a different signature for JDK classes with an exception for java.lang.Object.
See: http://cglib.sourceforge.net/xref/net/sf/cglib/core/DefaultNamingPolicy.html . The mapper doesn't take into account this naming convention (I've used only classes outside the JDK).
Costin Leau
added a comment - Through unit tests I've noticed that CGLib uses by default a different signature for JDK classes with an exception for java.lang.Object.
See: http://cglib.sourceforge.net/xref/net/sf/cglib/core/DefaultNamingPolicy.html . The mapper doesn't take into account this naming convention (I've used only classes outside the JDK). The contributed code is now superceded by the solution implemented for XSTR-239. Please reopen, if there's any issue left.
Show
Jörg Schaible
added a comment - The contributed code is now superceded by the solution implemented for XSTR-239 . Please reopen, if there's any issue left.
Jörg Schaible
added a comment - The contributed code is now superceded by the solution implemented for XSTR-239 . Please reopen, if there's any issue left. 
dummy object used for CGLib