Hi Shay,
Shay Hassidim wrote:
> Yes. Tnx. We are actually working together.
> What's the simplest way to instruct Xstream to treat classes extending
> from GregorianCalendar as GregorianCalendar? The problem exists with any
> derived class from GregorianCalendar. Its not a JPA problem.
As confirmed.
> Right now without creating a specific converter Xstream will have
> problems. It generates a huge xml that is cut off and missing some data.
This is true for any type that is not covered by the standard XStream
converter. Nevertheless, these converters will always handle concrete
classes only i.e. in the normal case only types delivered with the JDK.
> This cause the exception when de-serializing it back to object.
No, the problem is that a corner case in the SerializationConverter causes
this bug. When XStream fixes this bug, it does not have a lot influence on
the XML representation. What you will get is what you receive when you add
those 4 lines with the default implementations and aliases from my other
mail.
> I'm afraid also the ToStringConverter would not be optimized as the
> GregorianCalendarConverter since it store the GregorianCalendar to string
> content that is by far larger than the data Xstream store (timestamp and
> time zone).
The ToStringConverter is a match for XmlCalendar of XBeans, because it has a
unique string representation and can be recreated with XmlCalendar(String).
But it is no general solution.
> How the alias solution works?
As said, those aliases and default implementation settings will prevent the
buggy corner case in the SerializableConverter. XStream cannot provide a
generalized GregorianCalendarConverter for all derived classes of
GregorianCalendar, because it has no clue what additional members have been
added that have to be saved to recreate the original object. Therefore are
all "unknown" types handled by converters based on reflection (like the
SerializableConverter), which use a XML representation that contains all
info to recreate the original object.
In your special case I have no clue what this proxy actually does (resp.
what data it contains except that it inherits from GregorianCalendar). In
case you would like to get rid of the JPA proxies in the XML representation
at all, you might take a look at the XStream-Hibernate module and create
something similar for JPA.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
