|
[
Permlink
| « Hide
]
Kamal Fariz added a comment - 23/Jan/06 05:31 AM
I forgot to add that I am using 1.0-SNAPSHOT from January 23, 2006.
It looks like .NET server don't recognize an empty SOAPAction header (what is perfectly valid due to soap spec ) until its configured to do so. MS support adice to add [SoapDocumentService(RoutingStyle=SoapServiceRoutingStyle.RequestElement)] to service definiton
 , but since you don't have access to that service i'll try to find some workaround. If using the default ObjectServiceFactory and ServiceBean, the only way workaround I can see is to expose the action as a configurable property.
Can you send me you test project? I was a little busy last time and it would make it a little easer to fix.
The SoapAction going out should be "" - I am not sure why .NET would be having a problem with that. I think you can create a handler which does:
public void invoke(MessageContext context) { Maybe that will fix things for you? Ok, i think i know where is the problem. You service object isn't configured properly. Creating service in the way you did so, cause a tiny problem with ServiceFactory.
In your config, default ServiceFactory is used instead of AnnotationServiceFactory, thats why all information from annotation are lost ( including SaopAction ). When you create currencyConvertorService bean, you must specify a valid serviceFactory ( you can look at CurrencyConvertorClient class where all configuration is done ) or you can use CurrencyConvertorClient class directly to get service object configured like : CurrencyConvertorClient client = new CurrencyConvertorClient(); CurrencyConvertorSoap soap = client.getCurrencyConvertorLocalPort(); That should do the trick. In case you will have problems with this ( or emergency I am purposely not instantiating a special ServiceFactory as ServiceBean will instantiate the default ObjectServiceFactory. I am sure that if I use AnnotationServiceFactory I should be able to get this example working. I realize that using a bare interface file is not enough for XFire to be able to to have all the relevant information to generate the request XML. I assume that is why certain parameters are configurable, like namespace. The alternative to annotations is to use the WSDL document to provide all the necessary information.
I have looked at ServiceBean's code and made some changes for it to be able to call ServiceFactory's create(Class, QName, URL, Map) instead*. There are some other changes, like exposing portType etc. Most things work, SoapAction is populated and the server doesn't raise a Fault. The only stumbling block right now is that the binding provider does not use the WSDL for getSuggestedParamName, leaving me with <in0>, <in1>. I'm looking into how I can modify the Aegis binding provider or should implement a new binding provider that is backed by the WSDL document. Any thoughts on this?
The SOAP-Action attribute isn't handled on the server side correctly to. Given a WSDL with SOAP binding (snippet shown below)
<snip /> a successfully generated and deployed ws-server results in the expected HTTP transport binding — including the <snip /> XFire always generates an empty String as soapAction, this is because of the ambiguity from the spec what the purpose of soapAction should be.
Additionally, because Aegis mapping/XmlBeans is used on Thomas side, there is no connection through generation between the wsdl and the service, only the types are generated. SOAPAction is generated correctly now, ( i hope
 |
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Server did not recognize the value of HTTP Header SOAPAction: .
