Community
Participate
Working Groups
the root problem is that the .(de)serialize(byte[]) introduces another wrapper object that is part of the serialized bytes[] and expect that also to be there when deserializing. this has the effect the a serialize2string() cant be fed into desrialize(String) which makes no sense at all...
so far i have impel'ed a simple workaround that doesnt cover the attachments. imo the API should look and behave like this: - by default attachments are not serialized/deserialized - we still put their names in as it is now the case when using searialize2string() - there are overloads to also do this with attachments. in that case they are contained as base64 with in the XML. i know this is verbose but this makes most sense and what users would expect. for internal use we could also provide the better performing serialization that is in place ATM (rev 1128).
Since Thomas provided the workaround I reduced the severity to minor.
set to WONTFIX cause workaround seems to be sufficient.
closed
