Hi Daniel, Thanks for your answer.
Yes in fact that was what I decided to do because the placeholders for the out parameters ruined the whole idea of having simple POJOs. Suddenly my generated interfaces started having methods with long signatures and javax.xml.ws.Holder wrapper objects all over the place for my complex-type return objects. Do you think this is an issue with the JAX-WS specification, or is it simply a matter of implementation? I know that the convention for wrapped-style document/literal is to name the input messages with the operation name itself, however I don't know if this is strictly specified anywhere and if there is anything defined on how the response messages should be named. Afaik, the wrapped-style was introduced to enable a seamless transition from RPC to Document style at a programming language level, however with this kind of auto-generated code it is only applicable for simple return types. :( Regards, Josef -----Original Message----- From: Daniel Kulp [mailto:[email protected]] Sent: 12 January 2009 20:10 To: [email protected] Cc: Josef Bajada Subject: Re: Generating non-wrapped response I don't think this is doable. With JAX-WS, you can have complete "unwrapped" style where all the parts are individual params (holders for out/in-out) or bare where there are wrapper parts for both request and response. There isn't a way to have unwrap in/bare out. If you don't like the holders, I think the only option is to flip to bare mode and have TransactionRequest and TransactionResponse objects to work with. Dan On Friday 09 January 2009 7:15:21 am Josef Bajada wrote: > Hi, > > > > I am trying to develop my webservice in contract-first style using > document/literal encoding. I was interested in making my methods in > 'wrapped' style since this makes it easy for developers to have > RPC-style method signatures. However the response of these methods is a > complex-type element which has various members such as transaction code, > message etc. > > > > However, for some reason when I perform wsdl2java using CXF (v2.1.2) the > members of the response object are also put as parameters in the method > signature. The method is annotated with: > > > > @ResponseWrapper(localName = "transactionResponse", targetNamespace = > "http://mynamespace.com";, className = "my.package.TransactionResponse") > > > > And the signature of the method itself gets overcomplicated with all the > members of the TransactionResponse class being 'boxed' in > javax.xml.ws.Holder instances: > > > > @WebParam(mode = WebParam.Mode.OUT, name = "responseCode", > targetNamespace = "http://www.go.com.mt/webservices/EPG.xsd";) > > javax.xml.ws.Holder<java.math.BigInteger> responseCode, > > @WebParam(mode = WebParam.Mode.OUT, name = "responseMessage", > targetNamespace = "http://www.go.com.mt/webservices/EPG.xsd";) > > javax.xml.ws.Holder<java.lang.String> responseMessage, > > @WebParam(mode = WebParam.Mode.OUT, name = > "transactionTimestamp", targetNamespace = > "http://www.go.com.mt/webservices/EPG.xsd";) > > javax.xml.ws.Holder<javax.xml.datatype.XMLGregorianCalendar> > transactionTimestamp, > > > > While I would like that input request parameters get wrapped into the > RequestWrapper but the response not, because in my case this is a bit of > a nuisance. I tried to rename the response elements so that they don't > match the 'methodnameResponse' convention but it was in vain. > > > > Any idea how to solve this? > > > > > > Regards, > > > > Josef -- Daniel Kulp [email protected] http://dankulp.com/blog
