Bjorn Roche wrote:
>
> On Mar 20, 2012, at 3:37 PM, Jörg Schaible wrote:
>
>> Hi Bjorn
>>
>> Bjorn Roche wrote:
>>
>>> Hey all,
>>>
>>> First off, I heart XStream. I just wanted to share a problem I had
>>> recently and how I solved it. It seems to me the solution is unintuitive
>>> and hard to find. This maybe isn't a bug, but at the very least I think
>>> it should be easier to do what I needed to do, or maybe his needs to be
>>> a FAQ or something.
>>>
>>> So here's my story:
>>>
>>> I noticed my dates were not being converted the way I wanted. After much
>>> searching I found this: http://jira.codehaus.org/browse/XSTR-116 Ah hah!
>>> that's all I need to do!
>>>
>>> - first comment: that should be a FAQ or something. ISO8601 dates are
>>> pretty widely accepted as standard for XML, right? If they don't work
>>> automatically, it should be easy for people to figure out how to make
>>> them work, and I think the FAQ is the right place for that.
>>
>>
>> The ISO8601 converters are listed:
>> http://xstream.codehaus.org/converters.html
>
> Fair enough. So much of xstream is automagic that when a widely accepted
> format (standard?) is not default, it seems strange.
History. Actually today you might also use an instance of the DateConverter
instead:
xstream.registerConverter(
new DateConverter("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"));
[snip]
>>> Now here's the problem I don't really understand: the timestamp objects
>>> still converted like this:
>>>
>>> <cTime class="sql-timestamp">2012-03-17T20:44:00.490Z</cTime>
>>>
>>> So the date/time format is right, but the class annotation confuses
>>> XStream when trying to deserialize this.
>>
>> No, it is simply ignored, because the ISO8601DateConverter only creates
>> Date instances. And XStream will throw an exception afterwards, since it
>> expected the converter to produce a Timestamp.
>
> You say "No", but I think we are in agreement: this is a problem.
Meant: No, XStream is not confused ... ;-)
>>> The solution, which was
>>> counterintuitive to me, was this:
>>>
>>> XStream xstream = super.createXstream(mediaType);
>>>
>>
xstream.addDefaultImplementation(java.sql.Date.class,java.util.Date.class);
>>>
>>
xstream.addDefaultImplementation(java.sql.Timestamp.class,java.util.Date.class);
>>>
>>
xstream.addDefaultImplementation(java.sql.Time.class,java.util.Date.class);
>>> xstream.registerConverter(DATE_CONVERTER);
>>>
>>> That gets rid of the pesky annotation, although I suppose some other
>>> subclass could come along and mess things up.
>>
>> You simply suppressed the check of XStream. You still create only Date
>> instances. XStream will no longer care if your data structures (and your
>> application afterwards) expect something else. ClassCastExceptions are to
>> be expected.
>>
>>> - Third comment/question: Is this the best way? Am I missing something?
>>> If this is the best way, I think there should be a better way as this is
>>> unintuitive and potentially error prone if another date subclass comes
>>> along.
>>
>> Registering the ISO8601SqlTimestampConverter?
>>
>
> Okay. I'll try it.
You're welcome,
Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
