cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <>
Subject Re: SoapBindingInfo question
Date Fri, 10 Aug 2007 13:26:25 GMT
Daniel Kulp wrote:

>This is one area that does need a little cleanup.   The JAX-WS binding 
>ID's have managed to pollute the non-jaxws parts of the code in ways 
>they shouldn't have.    If you look at the cxf-extension-soap.xml file, 
>you'll see the soap binding is registered on several namespaces that it 
>probably shouldn't be.  It probably should be updated to only register 
>on the specific 1.1 and 1.2 namespaces, and the JAX-WS bindings should 
Or, if bindingIds other than the specific 1.1 and 1.2 namespaces are 
mapped by default to 1.1 (which I assume they are?) then this mapping 
should be *consistent*.
Registration of only the specific 1.1 and 1.2 namespaces may be 
difficult at this point because of backward compatibility issues.


>be mapped onto those in the JAX-WS layer.   JAX-WS complicates the 
>matter a little by doing wacky things with the binding ID.   Example:
>That munges the SOAP12 binding, the HTTP transport, and the MTOM enabled 
>property all together.   That should be separated into those three 
>things in the JAXWS layer.
>On Friday 10 August 2007 06:59, Andrea Smyth wrote:
>>The bindingId in the server endpoint of the hello_world sample is
>> whereas  in the endpoint of the ws_rm
>>demo it is
>>Both samples use wsdl first, and both wsdls have the same
>><soap:binding style="document"
>>element attached to their <wsdl:binding> element.
>>At the moment, this causes problems for RM when it builds up the
>>service model for the RM endpoint based on the service model for the
>>application endpoint.
>>In one case, it succeeds in creating a SoapBindingInfo, in the other
>>it throws an exception because the soap version cannot be determined
>>from bindingId
>>I can work around it by using the constructor for SoapBindingInfo that
>>takes the SoapVersion as an argument, but find the behaviour a bit
>>strange. Why do the two endpoints end up with different bindingIds in
>>the first place?
>>IONA Technologies PLC (registered in Ireland)
>>Registered Number: 171387
>>Registered Address: The IONA Building, Shelbourne Road, Dublin 4,

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

View raw message