Solved, that was the problem. thanks for the hint :-)
dkulp wrote: > > > Ah, yes. Not a valid wsdl. > > For doc/lit bindings, the parts in the messages should refer to > element declarations, not types. Using types in the parts is only > valid for rpc/lit bindings. > > Dan > > > > > On Jun 20, 2008, at 7:02 AM, _Eric_ wrote: > >> >> Here are the WSDL and the imported XSD >> http://www.nabble.com/file/p18027378/myproject.wsdl myproject.wsdl >> http://www.nabble.com/file/p18027378/myprojectdata.xsd >> myprojectdata.xsd >> >> PS: I did replace the company an project name (my boss doesn't like to >> spread informations on what projects we are working on). so the >> service name >> doesn't fit with the error message. >> >> >> dkulp wrote: >>> >>> >>> I'd have to see the wsdl to really determine what is going on, but I >>> think the "working" message is definitely wrong. According to the >>> soap spec, all children of the soap:body need to be qualified >>> elements. >>> >>> That said, this also looks to be a "doc/lit bare" style service which >>> is not WSI-Basic Profile compliant. While not really an issue for >>> CXF (in theory), it could cause interoperability problems. >>> >>> Dan >>> >>> >>> >>> On Jun 19, 2008, at 7:17 AM, _Eric_ wrote: >>> >>>> >>>> Hello forum, >>>> >>>> with Spring and CXF I made a webservice. I made a WSDL with an >>>> imported XSD >>>> containing the types to generate the client and the server side. But >>>> the >>>> server side does not exept the messages generated by the client and >>>> throws >>>> the following message: >>>> >>>> org.apache.cxf.interceptor.Fault: Message part >>>> {http://mycompany.de//myService}appId was not recognized. (Does it >>>> exist in >>>> service WSDL?) at >>>> org >>>> .apache >>>> .cxf >>>> .interceptor >>>> .DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java: >>>> 179) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java: >>>> 221) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport >>>> .ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport >>>> .servlet.ServletDestination.invoke(ServletDestination.java: >>>> 92) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport >>>> .servlet.ServletController.invokeDestination(ServletController.java: >>>> 214) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport.servlet.ServletController.invoke(ServletController.java: >>>> 151) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport >>>> .servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java: >>>> 170) >>>> at >>>> org >>>> .apache >>>> .cxf >>>> .transport >>>> .servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java: >>>> 148) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java: >>>> 710) at >>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803) >>>> at >>>> org >>>> .apache >>>> .catalina >>>> .core >>>> .ApplicationFilterChain >>>> .internalDoFilter(ApplicationFilterChain.java: >>>> 290) >>>> at >>>> org >>>> .apache >>>> .catalina >>>> .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: >>>> 206) >>>> at >>>> org >>>> .apache >>>> .catalina >>>> .core.StandardWrapperValve.invoke(StandardWrapperValve.java: >>>> 230) >>>> at >>>> org >>>> .apache >>>> .catalina >>>> .core.StandardContextValve.invoke(StandardContextValve.java: >>>> 175) >>>> at >>>> org >>>> .apache >>>> .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) >>>> at >>>> org >>>> .apache >>>> .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) >>>> at >>>> org >>>> .apache >>>> .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: >>>> 109) >>>> at >>>> org >>>> .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: >>>> 261) >>>> at >>>> org >>>> .apache.coyote.http11.Http11Processor.process(Http11Processor.java: >>>> 844) >>>> at >>>> org.apache.coyote.http11.Http11Protocol >>>> $Http11ConnectionHandler.process(Http11Protocol.java:581) >>>> at org.apache.tomcat.util.net.JIoEndpoint >>>> $Worker.run(JIoEndpoint.java:447) >>>> at java.lang.Thread.run(Thread.java:619) >>>> >>>> The message that does not work is: >>>> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/ >>>> envelope/"> >>>> <soap:Body> >>>> <ns2:appId xmlns:ns2="http://mycompany.de//myService"; >>>> xmlns="http://mycompany//myData";>12</ns2:appId> >>>> </soap:Body> >>>> </soap:Envelope> >>>> >>>> The message that works fine generated by soapUI from the WSDL: >>>> <soapenv:Envelope >>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ >>>> "> >>>> <soapenv:Header/> >>>> <soapenv:Body> >>>> <appId>12</appId> >>>> </soapenv:Body> >>>> </soapenv:Envelope> >>>> >>>> I my opinion both version are correct. >>>> http://www.nabble.com/How-to-change-the-namespace-position-in-the-generate-xml-message-(SOAP-message)--to16176819.html#a16195360 >>>> This posting explanes a similar problem. But I guess this is to >>>> solve on >>>> the server side. >>>> Can anybody give a hint? >>>> >>>> Greetings Eric >>>> >>>> PS: CXF 2.1, Spring 2.0.8 >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/namespace-and-%22Message-part-was-not-recognized%22-tp18005778p18005778.html >>>> Sent from the cxf-user mailing list archive at Nabble.com. >>>> >>> >>> --- >>> Daniel Kulp >>> [EMAIL PROTECTED] >>> http://www.dankulp.com/blog >>> >>> >>> >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/namespace-and-%22Message-part-was-not-recognized%22-tp18005778p18027378.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > > -- View this message in context: http://www.nabble.com/namespace-and-%22Message-part-was-not-recognized%22-tp18005778p18108520.html Sent from the cxf-user mailing list archive at Nabble.com.
