Dan - thanks for the pointers. Turns out this issue happens if the CXF jars are loaded separately by two CXF web apps.
The web-app that came up first was getting the CXF jars from tomcat shared lib. The web-app that came up second was getting the CXF jars from it's own WEB-INF/lib. This was throwing CXF off when generating the wsdls. Why would this be? When we changed the second web-app to also use the CXF jars from tomcat shared lib, everything seems to work fine. tia, rouble On Thu, Dec 8, 2011 at 10:54 AM, Daniel Kulp <[email protected]> wrote: > On Wednesday, December 07, 2011 4:24:20 PM rouble wrote: >> This is a java first service, so CXF is generating the faulty schema. >> >> We have two (almost identical) boxes, with tomcat. > > I love the "almost identical".... :-) > >> On one this issue >> is reproducible, on the other it is not. The war file is the same. >> >> Any tips on how to debug this further? It seems to be related to how >> CXF generates the context, because the schemas are generated from the >> context. > > If you can do so, can you breakpoint in JAXBUtils.generateJaxbSchemas and, > prior to the return, kind of dig into the list of DOMSource objects and see if > the root elements are properly qualified or not. > > The main "cause" of something like this MAY be an older version of Xerces or > other XML parser that could possibly be picked up. Maybe from the tomcat > shared/lib dir of jre/lib/endorsed or similar. It could be the DOM > implementation is bad. Another issue COULD be different versions of JAXB > being picked up. Check that as well. > > Dan > > > > >> >> tia, >> rouble >> >> On Wed, Dec 7, 2011 at 2:50 PM, Daniel Kulp <[email protected]> wrote: >> > On Wednesday, December 07, 2011 2:43:11 PM rouble wrote: >> >> After some more CXF debuggging: >> >> >> >> This is what the top of the document looks like in the working case, >> >> when getNamespaceURI() does not return null: >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; >> >> xmlns:tns="example.com" targetNamespace="example.com" version="1.0"> >> >> >> >> and this is what the top of the document looks like in the non-working >> >> case, when getNamespaceURI() returns null: >> >> <?xml version="1.0" encoding="UTF-8"?> >> >> <schema xmlns:tns="example.com" >> >> xmlns:xs="http://www.w3.org/2001/XMLSchema"; >> >> targetNamespace="example.com" version="1.0"> >> > >> > Actually, they aren't the same at all. In the second case, the schema >> > is NOT in a namespace. It would need the xs: prefix or it would need >> > an xmlns="http://www.w3.org/2001/XMLSchema";. In this case, the schema >> > really is invalid. >> > >> > Now, the next question is: where/how is that schema generated? Is CXF >> > generating that invalid schema? >> > >> > Dan >> > >> >> Notice that the schema is in the W3C namespace, it is just ordered >> >> differently. And for some reason, >> >> d.getDocumentElement().getNamespaceURI() is set to null. >> >> >> >> Also, if I take out the code that throws the exception in >> >> AbstractDataBinding.addSchemaDocument, "Invalid schema document passed >> >> to AbstractDataBinding.addSchemaDocument, not in W3C schema >> >> namespace", I start to see a bunch of: >> >> factory.ReflectionServiceFactoryBean - Schema element >> >> {http://example.com/}foo references undefined type >> >> {http://example.com/}foo for service {http://example.com/}FooService. >> >> >> >> Any ideas how I can debug why d.getDocumentElement().getNamespaceURI() >> >> is being set to null in some cases? >> >> >> >> tia, >> >> rouble >> > >> >> On Tue, Dec 6, 2011 at 3:19 PM, Daniel Kulp <[email protected]> wrote: >> > -- >> > Daniel Kulp >> > [email protected] - http://dankulp.com/blog >> > Talend Community Coder - http://coders.talend.com > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com
