Update 2010-09-29:
So, depsite being able to trigger it live, and knowing that it’s always a problem with an exception being thrown by the web service, and something in the soap fault parsing being broken, I still haven’t been able to actually fix this. Sometimes I get a parser cast error for a soapfault, sometimes I don’t. Classloader hell somewhere I presume. This one still bites me a lot, and I don’t feel any closer to permanently solving it than I did on day 1, if anything I feel further from resolution, because of how much I’ve tried.
Original post below….
Not much information out there about this one. What little there is will indicate some sort of class path or library conflict. That may be true, but there’s other ways of getting here. I finally managed to trigger it myself today, and now I know what causes it. And I’m disgusted.
DISGUSTED
Now, admittedly, I’m having a hard time coming up with a test case for this, but it very much appears that this is happening when certain characters that are illegal in XML are returned via a webservice call. FYI, I’m using JAX-WS wsdl first services, with JAX-WS service clients. The _clients_ throw the error.
After eventually finding one of the problem calls, I found that the invoke was actually failing on the service side, and because ERICSSON ARE MORONS, the error message included ^c in the output. While this got sent back to the client without the service failing, the client exploded, with the delightfully helpful xml parser casting error.
So, JAX-WS RI, despite being billed as non-intrusive, and something that let’s you expose your existing services as webservices, is HIGHLY INTRUSIVE, and requires that _you_ take pains to make sure you _NEVER_ send out any invalid xml. Even in you string fields, where you should be able to use what you want. Because, you know, the library’s just exposing my service.
Still, there’s a fine tradition of this moronic behaviour. XFire does the same thing. [1] They flat out refused to accept that this was something the webservices library should be handling.
[1] You’ll get something like: com.ctc.wstx.exc.WstxUnexpectedCharException: Illegal character ((CTRL-CHAR, code 3)) at line blah…
Leave a Comment