On Thursday 25 March 2010 10:02:07 am J. Aparicio wrote: > OK, found out what the problem was. > > The xsd in question includes a DOCTYPE declaration. Of all the involved > wsdl and xsd documents in the app, it's the only one with a DOCTYPE > declaration. Taking it out of the document allowed CXF to return the xsd.
Well, that's interesting. Unexpected, but interesting. > Now, my question (which doesn't belong to cxf anymore) is whether that > DOCTYPE declaration should be there at all, or if the standard xsd was > revised at some point and the DOCTYPE declaration taken out. The latest > version I've been able to find lies at > http://www.w3.org/2005/08/addressing/ws-addr.xsd, and DOESN'T have a > DOCTYPE declaration. > > On the CXF-related side, is it legal for StaxUtils to choke on such a node > type? Can't it just ignore it? I would have also expected it to just ignore it. Not sure why it wouldn't be. Is there any way you could create a small testcase that shows it throwing the exception? That would make it easier to debug it. I'm really not sure how a DOCTYPE would cause this. Very bizzarre. Dan > Can't it just spit it out as it is? I guess > these last questions belong to cxf-dev, though. Or maybe the > StaxUtils-specific list. > > Thanks to all for reading this :-) > > J. Aparicio wrote: > > Hello. I have a wsdl which imports another wsdl, which I can not change. > > That second wsdl imports some xsd schema, which in turn import another > > xsd schema. Again, I can't change those xsd schemas (they are standard). > > > > The problem is the CXFServlet (through a Tomcat server) serves the first > > wsdl, the second wsdl and the first xsd OK, but fails to serve the second > > xsd. > > The first xsd schema imports the second one via a line like this: > > > > <xsd:import namespace="http://www.w3.org/2005/08/addressing"; > > schemaLocation="../types/ws-addressing-0805.xsd"/> > > > > The ../types/... reference is resolved OK on the filesystem, cxf's > > wsdl2java has no problem with it. But it is inaccessible via the > > CXFServlet. That means I can not give the CXFServlet url to implementors > > of clients, because they can not get the second xsd schema. > > > > I've tried the command line wsdl2java and the maven plugin as well, with > > no success on either. > > > > I don't know if it may have an impact, but I'm generating the code > > including the "-noAddressBinding" option to wsdl2java. This is because I > > have to extend the WS-Addressing classes, which otherwise come out as > > final. > > > > I've tried CXF 2.2.5 and 2.2.7, Java5 and Java6, Tomcat5.5 and Tomcat6 > > combinations, but all of them fail at the same point. > > > > What else could I try? > > > > Thank you :-) -- Daniel Kulp [email protected] http://dankulp.com/blog
