Egyik régi ismerősöm keresett meg egy elég húzós problémával. Egy webszerviz egy saját típusból két példányt kap paraméterül, ám csak az első megy át, a második null lesz. Ha tömbben adják át őket, akkor is. Ha felcserélik a kliens proxy oldalán, akkor is a második null.
A típus saját XML Serializálást használ, ez már eleve gyanús volt, azonban elsőre nem tűnt fel benne semmi ravaszság. Beraktam egy kis WebService Trace Extension kódot, hogy lássam, rendesen elküldi-e a kliens a SOAP csomagot, de igen, a boríték sértetlen és teljes volt.
A szerializáló kódot figyelmesebben megnézve aztán előbukkant a probléma. A saját serializálásuk nem direktben használta a kapott XmlReader-t, hanem egy XPathDocumenten keresztül. Így magasabb absztrakciós szinten lehet programozni, ami ebben az esetben nagy könnyebbség. Igen ám, de az XPathDocument cache-el. Nem csak simán, hanem előreolvas a drága, ami neki jó, mert így pl. meg tudja mondani van-e gyermekeleme egy elemnek, stb. Csakhogy esetünkben annyira mohó volt, hogy a kapott XmlReader-t teljesen végignyalta, így az első paraméter deserializálása után a reader már a SOAP csomag végén állt, így a következő deserializálás megkapta a nagy semmit.
Persze belegondolva semmi panasz nem lehet az XPathDocumentre, senki nem mondta, hogy nem olvashat előre. De elsőre ez nem esett le nekem se.
Mi a megoldás erre a problémára? Pőrén az XmlReadert kell használni, kínosan ügyelve arra, hogy minden típus és beágyazott típus pontosan csak annyit tekerje előre a readert, hogy a saját adatait ki tudja olvasni, egy centivel se előbbre. Disciplined programozó kell ehhez, mint ahogy a tőzsdei kereskedéshez is, Elder szerint. :)

Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.