Now as a desperate move I redo my project using XML bindings instead of JAXB2 bindings because it seems the JAXB2 it doesn't carry properly the metadata based on the annotations... Even if I wanted really really much to use JAXB2 because all the advertised advantages .......
On Fri, 2007-11-05 at 10:05 -0400, Dragos Pavel wrote: > 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 > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
