Re: Generating non-wrapped response

[mbyrne00 <mb...@gmail.com>]

Hi,

I know this is an old post, but thought I'd note a way around this since
this thread comes up top of my Google searches.

I got around this issue "accidentally" by defining an abstract complexType
and extending it. It was only when I didn't need to extend the abstract
complexType any more that I discovered this problem and started trying to
search for a solution.

  <xs:complexType abstract="true" name="AbstractResponse">
    <xs:sequence>
      <xs:element minOccurs="1" name="responseHeader"
type="tns:ResponseHeader"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="MyResponse">
    <xs:complexContent>
      <xs:extension base="tns:AbstractResponse">
        <xs:sequence>
          <xs:element minOccurs="0" name="someAdditionalVariable"
type="xs:string"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


If you use MyResponse type in your element definition this will create the
desired method signature without splitting into multiple WebParam.Mode.OUT
parameters and a void return.

Hope that helps.



dkulp wrote:
> 
> On Monday 12 January 2009 5:10:09 pm Josef Bajada wrote:
>> 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?  
> 
> It's a JAX-WS specification issue.   The current spec only allow either 
> complete bare mode or complete unwrapped mode.   No middle ground.   On an 
> interesting timing note, this topic came up yesterday  on the  jaxws spec 
> list for discussion for a future version.   Thus, we'll see.    Note:
> they've 
> logged a bug against the reference impl as well:
> https://jax-ws.dev.java.net/issues/show_bug.cgi?id=659
> 
> Thus, it is getting some visibility. 
> 
>> 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.
> 
> Yea.  Spec dictates this.   
> 
> 
>> 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. :(
> 
> Well, not really.   RPC can have multiple outs as well in many programming 
> languages.   C/C++ can pass by pointer/reference and such.   Thus, even
> with 
> an RPC style service, Holders could be required.
> 
> Dan
> 
> 
> 
>>
>> Regards,
>> Josef
>>
>>
>>
>>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: 12 January 2009 20:10
>> To: users@cxf.apache.org
>> 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
> dkulp@apache.org
> http://dankulp.com/blog
> 
> 

-- 
View this message in context: http://old.nabble.com/Generating-non-wrapped-response-tp21371200p28944936.html
Sent from the cxf-user mailing list archive at Nabble.com.