I found something out. I was experimenting with xmlbeans again and found out that the used schema has an impact on the generated client.
If the services wsdl uses DOCUMENT LITERAL WRAPPED the interface MathPortType contains: @WebMethod(operationName = "sum", action = "") @WebResult(name = "out", targetNamespace = "http://192.168.0.12:8080/math/services/process") public XmlObject ivmRefreshSession( @WebParam(name = "first", targetNamespace = "http://192.168.0.12:8080/math/services/process") int first, int second); If the services wsdl uses DOCUMENT LITERAL BARE the interface MathPortType contains: @WebMethod(operationName = "sum", action = "") @WebResult(name = "sumOut", targetNamespace = "http://192.168.0.12:8080/math/services/process") public SumoutDocument sum( @WebParam(name = "first", targetNamespace = "http://192.168.0.12:8080/math/services/process") FirstDocument first, @WebParam(name = "second", targetNamespace = "http://192.168.0.12:8080/math/services/process") SecondDocument second); As you can notice for doc/literal-wrapped the interfaces methods take the parameters direct, but the return type is XmlObject! That reminds me of that issue: http://www.nabble.com/XFire-generated-Client-and-XmlBeans-tf2333830.html#a6493595 With doc/lit-bare the methods take the beans, but how you can see, they take 1:1 bean : parameter! It looks to me like a not wanted behaviour (error?). Maybe that matter is allready fixed. I use xFire 1.2.2. Hope someone can help with that. > I have a question to the xFire client. Is it possible to invoke request by > using beans as input and return parameters? For example a call for a method > sum(): int sum(int first, int second); > > // use from WSDL generated client > MathClient client = new MathClient(); > MathPortType talk = > client.getMathHttpPort("http://192.168.0.12:8080/math/services/process"); > // use bean from WSDL > SumDocument req = new SumDocument(); > req.setFirst(25); > req.setSecond(747); > // invoke request, result is a bean again > SumResponseDocument resp = talk.invoke("sum", SumDocument); > // or alternate > // SumResponseDocument resp = talk.sum(SumDocument); > > The last days I spend a lot of time in investigating that matter but with > no success. I know I could use that approach: > > Service serviceModel = new > ObjectServiceFactory().create(MathPortType.class); XFire xfire = > XFireFactory.newInstance().getXFire(); > XFireProxyFactory factory = new XFireProxyFactory(xfire); > MathPortType client = (MathPortType)factory.create(serviceModel, > "http://192.168.0.12:8080/math/services/process"); > > int result = client.sum(25, 747); > > We decided to go the other way: over beans. XmlBeans looked promising and > the page "XMLBeans Client Generation.html" from the manual in the > distribution showed some example that seems to fit perfect. Unfortunately > it's out of date. The class to generate the client doesn't even exist > anymore. The interfaces methods don't take the xmlbeans. > > All documentations about using clients I've seen so far are for the dynamic > proxy clients xFire is using now. That one doesn't capsule input and output > parameters. Even if you generate the client with wsgen the result is the > very same. Did I miss something? Is there a way to feed the client with > xmlbeans? I don't want to rewrite xFire... > > I hope someone has an anwer to my question. > > Thank you > > R.M. > > --------------------------------------------------------------------- > 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
