Looks like the doctype adds one more event/node to the picture, and something trips over it.
On Thu, Mar 25, 2010 at 2:46 PM, Daniel Kulp <dk...@apache.org> wrote: > 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 > dk...@apache.org > http://dankulp.com/blog >
