My outgoing SOAP is correct and contains all data, but on the server side because of the wrong generated wsdl (contains duplicate schema) it can not resolve correct the object types and of course I get a java.lang.NullPointerException trying to access the data from the service (yes, I checked all data passed through and traced with TCPMON as well the outgoing SOAP is correct). My original wsdl (used to create my service) that I coded is correct (checked it again and again).
Now I implemented this workaround = tell XFire service to use original WSDL not the generated one, I checked the path so the file must be found correctly, but XFire ignores it. What I mention in my previous post it doesn't matter (about it worked one time). Can somebody help me with the wrong generated wsdl (all info in the thread) or with what I'm doing wrong for the workaround to work as exepected ? At this point I don't have many leads on how to fix this big issue... On Thu, 2007-10-05 at 23:40 -0400, Dragos Pavel wrote: > 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 > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
