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.

December 2, 2008 / by Zsolt Soczó

Vigyázni az XPathDocumenttel

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.

LEAVE A COMMENT

2 COMMENTS

  • hrongyorgy December 3, 2008

    Elhiszem hogy valoban ez a problema, viszont ez akkor is implementacios bug az XPathDocument reszerol, hiszen ha eloreolvas, akkor a masodik objektumnak minden emberi szamitas szerint cache-bol kell jonnie. Mivel 1 darab objektumot mar deserializalt, a pointernek a kovetkezo objektumon kellene allni a cachen belul, a SOAP uzenet meg ez esetben a vilagon senkit nem erdekel.

  • Soczó Zsolt December 3, 2008

    Jogos, ám itt az volt, hogy sok XPathDoksit nyitottak ugyanarra a readerre. Ha egy doksinál maradtak volna, akkor jó lett volna az XPathDocumentes megoldás is. Köszi az ötletet.