Just a minor correction: based on more tests on our real XML, the
example below probably doesn't show the bug, because resolveIDFor: never
gets called - presumably because all ids at the outer level are already
read. A better example would thus probably be:
<person name="John" id="john">
<address href="#home"/>
</person>
<person name="Jane" id="jane">
<address id="home" street="Home St." town="Hometown"/>
</person>
<person name="Fred" id="fred"/>
Steve
> -----Original Message-----
> From: Steven Kelly [mailto:
[hidden email]]
> Sent: 30 August 2006 23:45
> To:
[hidden email]
> Subject: Bug in href unmarshaling?
>
> It looks to me like there's a dangerous bug in unmarshaling href/id
> pairs in 7.4.1's XMLObjectMarshalingManager>>resolveIDFor:. If the id
> mentioned in a href has not yet been found (e.g. it comes later in the
> document), the whole document is searched for all its id's to populate
> the idMap, and the last id in the whole document is returned -
> regardless of whether its value matches the requested href.
>
> E.g. in the following document, John's address would be set to a
Person,
> Fred - even though Fred is not of type Address and has the wrong id:
he
> just has the misfortune to be last in the file.
>
> <person name="John" id="john">
> <address href="#home"/>
> </person>
> <address id="home" street="Home Street" town="Hometown"/>
> <person name="Fred" id="fred"/>
>
> The bug seems to have existed since at least 7.2. I've attached a
> correction.
>
> Steve