Thanks for your replies guys,
Apologies, should of thought to include version information.
I'm using JDK 1.6 and xstream is version 1.4.5, pulled in via maven
dependency...
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.4.5</version>
</dependency>
It did occur to me too that it might be related to the sets, maybe a
compareTo() method is referencing an ID attribute which is getting it in a
muddle but the ones I checked yesterday seem to order by sequence attributes or
name attributes, I'll look further.
Also, I'll try different mode and see what happens, and let you know, hopefully
will solve issue.
Thanks,
Dale
-----Original Message-----
From: Ken Campbell [mailto:[email protected]]
Sent: 07 November 2013 10:49
To: [email protected]
Cc: Dale Ellis
Subject: RE: [xstream-user] Re: Converting an object back from XML
Hi Dale
Have you tested with different XStream modes? You are using relative paths and
nothing has a unique identifier after you strip them out. The ID mode might
solve your problem.
Regards
Ken
-----Original Message-----
From: Jörg Schaible [mailto:[email protected]]
Sent: 07 November 2013 10:23
To: [email protected]
Subject: [xstream-user] Re: Converting an object back from XML
Hello Dale,
which version of XStream are you using? What JDK (vendor and version)? Can you
paste the output of:
================ %< ==============
$ java -cp xstream-<VERSION>.jar com.thoughtworks.xstream.core.JVM
================ %< ==============
Basically I see no reason, why a field "id" should be problematic in any way.
I can see quite a lot "sorted-set" types in the XML which are mapped to
java.util.TreeSet. What is the sort criteria, e.g. for StageFieldDefinition?
Just for looking at the XML it is not obvious. At least it is neither "id"
nor "sequence". Is it the name that is used in the compareTo method?
Regards,
Jörg
Dale Ellis wrote:
> Hi all,
>
> I'm facing an issue at the moment with xstream which I have pin
> pointed the problem.
>
> I have an object called CaseType. What happens is I convert the object
> to xml, when I strip out all the id attributes and then convert it
> back. What happens is that depending on the case type object, the
> fromXML() method just hangs forever.
>
> The Code...
>
> // Remove all the ID's
> log.debug("Null all the ids");
> String xml = parser.toXML(contentObject);
> String idPattern = "<id>(.+?)</id>";
> xml = xml.replaceAll(idPattern, "");
>
> log.debug("Checking that export ("+ contentObject.getClass() +")
> data can be re-imported"); Object testObject =
> parser.fromXML(xml); log.debug("Object (" + testObject.getClass()
> + ") Successfully imported back");
>
> so the parser.fromXML() method hangs. If I remove the 2 lines that
> replace the id's it works fine...
>
> // Remove all the ID's
> log.debug("Null all the ids");
> String xml = parser.toXML(contentObject);
>
> log.debug("Checking that export ("+ contentObject.getClass() +")
> data can be re-imported"); Object testObject =
> parser.fromXML(xml); log.debug("Object (" + testObject.getClass()
> + ") Successfully imported back");
>
> In the main, removing the ID's doesn't cause an issue but for some
> CaseType objects it does. Looking into the xstream source there
> doesn't seem to be any debug I can turn on to better understand why is
> happening, I did start to step it, but looks to recursively call and I
> wasn't really following the flow.
>
> I have attached to xml files, one is the xml with the ID's striped
> out, the other without (which works), using a compare tool, the XML
> looks exactly what I'd expect, can anyone suggest what is going on?
> For completeness here is the XStream object (parser variable) ....
>
> protected XStream getCaseTypeParser() {
> XStream xStream = new XStream();
>
> xStream.alias("caseType", CaseType.class);
> xStream.alias("template", CaseTypeTemplate.class);
> xStream.alias("templateIndex", CaseTypeTemplateIndex.class);
> xStream.alias("templateIndexData",
> CaseTypeTemplateIndexData.class); xStream.alias("caseTypeLink",
> CaseTypeLink.class); xStream.alias("stage",
> StageDefinition.class); xStream.alias("stageTransition",
> StageTransitionDefinition.class);
> xStream.alias("stageTransitionCondition",
> StageTransitionCondition.class);
> xStream.alias("stageTransitionAction",
> StageTransitionAction.class); xStream.alias("stageField",
> StageFieldDefinition.class); xStream.alias("action",
> CaseTypeAction.class); xStream.alias("task",
> TaskDefinition.class); xStream.alias("field",
> CaseTypeFieldConfig.class); xStream.alias("userValueListRule",
> UserValueListRule.class); xStream.alias("taskTypeAction",
> TaskTypeAction.class); xStream.alias("participantType",
> CaseTypeParticipantType.class); xStream.alias("interactionType",
> InteractionType.class);
>
> return xStream;
> }
>
> Thanks
>
> Dale Ellis
>
>
>
> Senior Developer
>
>
>
> Serengeti Systems
>
> Part of the Netcall group
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This message was scanned at Thursday, November 7, 2013 10:23:22 AM GMT by Trend
Micro IMHS on behalf of White Clarke Group
This message was scanned by Symantec Messaging Gateway at White Clarke Group -
www.whiteclarkegroup.com.
White Clarke Group Ltd - Registered in England - Registered number 03435619.
Registered address: 26 Red Lion Square, London, WC1R 4AG.
This message was scanned at Thursday, November 7, 2013 10:48:44 AM GMT by Trend
Micro IMHS on behalf of White Clarke Group - www.whiteclarkegroup.com.
White Clarke Group Ltd - Registered in England - Registered number 03435619.
Registered address: 26 Red Lion Square, London, WC1R 4AG.
