Hi Jörg

Thanks for your reply.

Initially I was thinking along the lines that it would be overwriting
the first alias, but as it happened to work given the right sequence
I suspected that one could have an alias per name-class pair.
Especially since the classes that gets instantiated during unmarshal
are of the correct types and I only have the problem when one of them
occur as a implicit list.

As for the two "Nicks" I understand that the "name" cannot be a xpath
expression hence /doc/link and /doc/intro/link cannot be used to
indicate that these tags should be mapped to different classes.

Keeping the analogy with the names, I thought what I saw happen when
it worked, was that the class name acted as a sirname. So it would be
possible to differ between Nick UrlLink and Nick ImageLink so to
speak...

I'll check out the convert stuff again. After my first quick look at
some of the examples I came to the conclusion that I did not have the
position in terms of the xpath so I could not handle it that way, but
as you point out there are other indicators that can be used.

Brs
Claus

2012/2/29 Jörg Schaible <joerg.schai...@scalaris.com>:
> Hi Claus,
>
> Claus Priisholm wrote:
>
>> I been using XStream with great results for a number of tasks, but now I
>> run into a problem that seems to boil down to the order in which the
>> XStream object is configured.
>>
>> I've made a simplified example:
>>
>> <doc>
>>   <intro>
>>     <link>
>>       <url>/foo/bar</url>
>>     </link>
>>   </intro>
>>   <link>
>>     <url>/up/down</url>
>>     <image>cat.jpg</image>
>>   </link>
>> </doc>
>>
>> The setup is like:
>>
>> XStream xstream = new XStream();
>> xstream.alias("doc", DocText.class);
>> xstream.addImplicitCollection(DocText.class, "links");
>> xstream.alias("intro", Paragraph.class);
>>
>> xstream.alias("link", UrlLink.class); // 1
>> xstream.alias("link", ImageLink.class); // 2
>
>
> The second definition clobbers the first one.
>
>
>> The gist of the classes:
>>
>> public class DocText {
>> private Paragraph intro;
>> private List<ImageLink> links;
>> }
>>
>> public class Paragraph {
>> UrlLink link;
>> }
>>
>> public class UrlLink {
>> String url;
>> }
>>
>> public class ImageLink {
>> private String url;
>> private String image;
>> }
>>
>> When the sequence of the lines marked 1 & 2 is as shown it works.
>
>
> It works only, because the XML actually contains an ImageLink.
>
>
>> When
>> they change place it throws the following exception:
>>
>> No such field com.codedroids.oc.schema.dao.UrlLink.image
>> ---- Debugging information ----
>> field : image
>> class : com.codedroids.oc.schema.dao.UrlLink
>> required-type : com.codedroids.oc.schema.dao.UrlLink
>> converter-type :
>> com.thoughtworks.xstream.converters.reflection.ReflectionConverter
>> path : /doc/link/image
>> line number : 9
>> class[1] : com.codedroids.oc.schema.dao.DocText
>> version : null
>> -------------------------------
>
>
> You'd get the same exception for the first setup if your XML contained an
> UrlLink.
>
>
>> If DocText has a simple field called link rather than a list of them, then
>> it works either way (after removing the xstream.addImplicitCollection() of
>> course).
>>
>> The problem is that I am trying to get the xstream configuration generated
>> automatically from the related schema definition and thus cannot be sure
>> in which order the various alias'es gets invoked.
>
>
> Your setup *is* ambiguous.
>
>
>> I haven't tried using annotations since there places where the same class
>> is mapped by more than one tag name - this works fine with alias'es but
>> with annotation I can only map it to one tag name (or perhaps I'm
>> mistaken)
>
>
> Annotations make no difference here.
>
> See, if you have two boys and name them both "Nick", so would you expect
> that they know whom you mean, when you shout after one of them?
>
> Aliases define normally a 1:1 relation. The ReflectionConverter has to
> recover from the alias name the required class type to instantiate the
> appropriate object. If you use the same alias more then once, than the
> latest definition will win. And in case of annotations you cannot even
> define the registration sequence.
>
> What you can do is to write a custom converter that can handle all classes
> using the same alias. As long as it can detect what it has to create at
> deserialization time, anything is fine. In your case it should create an
> ImageLink if the "link" element has an additional "image" element as child
> and an UrlLink otherwise.
>
> See the converter tutorial, how to write such converters, it's an easy task.
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to