Hi All, I found a jira bug for the similar issues that occurs for my web service: http://jira.codehaus.org/browse/XFIRE-582 Exactly like it's described in the bug - "The generated WSDL that XFire displays through the Web-app also displays a similar issue, creating an additonal schema where only ~one~ existed in the original WSDL." - this is happening in my case as well. I know this supposed to be fixed in the XFire 1.2.4 that I use but it's still occurring.
I also observe that the generated wsdl contains (beside an additional schema) wrong ns1, ns2, ns3 because of the presence of an additional xmlns:ns1 in the wsdl:definitions (even I have only one tns in original wsdl...). So because of wrong schema and target ns I tried to use : http://osdir.com/ml/java.xfire.user/2006-05/msg00067.html Because of this I tried to tell XFire service to use original WSDL , not the generated one. I introduced on the server side (service implementation class): ---------------------------------------------------------------------- // get registry from the XFire instance XFire xfire = XFireFactory.newInstance().getXFire(); ServiceRegistry serviceRegistry = xfire.getServiceRegistry(); //ddd - workaround for the wsdl: org.codehaus.xfire.service.Service service = serviceRegistry.getService("Service"); try { File originalWSDL = new File ("/usr/local/..../wsdl/Service.wsdl"); service.setWSDLWriter(new ResourceWSDL(originalWSDL.toURL ())); System.out.println ("----------------"+originalWSDL.getAbsolutePath()+"-----------------"); } catch (MalformedURLException e) { e.printStackTrace(); } ------------------------------------------------------------------------ I want the published wsdl to be correct and in sync with the original one created by me that's all. I introduced on the client side (even if is not necessary because I'm interested only on the server side and that's because the generated wsdl is not correct!) : ------------------------------------------------------------------------ //creating map for document literal Properties props = new Properties(); props.put(AnnotationServiceFactory.STYLE, SoapConstants.STYLE_DOCUMENT ); props.put(AnnotationServiceFactory.USE, SoapConstants.USE_LITERAL ); //ddd-transform to bottom-up design-scenario org.codehaus.xfire.service.Service srvcModel = new AnnotationServiceFactory().create(lixar.Service.class, props); //ddd - workaround for the wsdl: try { File originalWSDL = new File ("/usr/local/..../wsdl/Service.wsdl"); srvcModel.setWSDLWriter(new ResourceWSDL(originalWSDL.toURL ())); System.out.println ("----------------"+originalWSDL.getAbsolutePath()+"-----------------"); } catch (MalformedURLException e) { e.printStackTrace(); } ................... ------------------------------------------------------------------------ The file path is 100 % correct, I printed it out and double checked it. Usually Xfire ignores this setting and I access the generated wsdl which is wrong; I say usually because only one time it worked and I saw the correct original wsdl. The only thing that I changed for that try was the url for the <soap:address location="http://dddpavel- lnx.dynadocs.com:8080/goodenergylixar" /> , modified to <soap:address location="http://dddpavel-lnx.dynadocs.com:8080/goodenergylixar/Service? wsdl" /> because I traced the log on JBoss and I observed that only when using full url I get a correct HTTP 200 on the server side... Anyway I must have changed something else, I was playing only with the url (from Service name to Service?wsdl for tns and target namespace that was all I touched in the original wsdl, I know was late and tired, it happens) but when I retried I never was able to restore the right config for the wsdl in order to get the original one instead of the generated wsdl by XFire. Please help. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
