Simon Laws wrote:
I'm trying to get a handle on a policy problem where I get a NPE in the Axis runtime. The NPE is caused because Axis is failing to find a named operation. It's looking for an operation of the form{http://helloworld}getGreetingsbut failing as the operation is registered in the binding inside the Axis service model with the name{http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService}getGreetingsThis seems to come back to how we generate WSDL. The generated WSDL inside the WS Binding in this case imports the real WSDL that was specified in an interface.wsdl statement. The generated WSDL [1] is given the target namespace {http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService} while the original WSDL retains the target namespace {http://helloworld}. Axis is getting confused when it pulls binding and porty type information from different parts of the WSDL definition. In this case, for example, there is an operation defined in the binding{http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService}getGreetings Which has a different QName to that defined in the original port type {http://helloworld}getGreetingsAnyone know why we generate a targetNamespace for this wrapper WSDL which takes the original namespace and adds the service name to the end of it?
The SCA 1.0 Bindings spec says the namespace for the generated binding elements is HTTP base URI / Component Name / Service Name The rather convoluted target namespace that you see in this generated file is a result of following this algorithm, with a bit of $promoted$ noise thrown is. (The "base URI" portion is debatable, as this term isn't clearly defined by the spec.) This namespace only applies to the elements defined within the generated WSDL file. So it affects the namespace of the binding definition, but it shouldn't affect the namespace of the global elements used by message parts within the portType referenced by the binding (i.e., what goes on the wire). In this example the portType is "ns0:HelloWorld" which refers to global elements in the correct namespace "http:/helloworld" So this looks to me like an Axis bug with namespaces for imported portTypes not being handled correctly. It seems the binding's namespace is being used to register these operations instead of the correct namespace as specified in the portType. Where in Axis is this registration happening? Which version of Axis is being used? With this information I could dig around a bit in the Axis code. Simon
Simon [1] <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="HelloWorldServiceComponent.$promoted$HelloWorldService" targetNamespace="http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService" xmlns:ns0="http://helloworld" xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/"> <wsdl:import namespace="http://helloworld" location="/HelloWorldService?wsdl=wsdl/helloworld.wsdl"> </wsdl:import> <wsdl:binding name="HelloWorldBinding" type="ns0:HelloWorld"> <SOAP11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getGreetings"> <SOAP11:operation soapAction="urn:getGreetings"/> <wsdl:input name="getGreetingsRequest"> <SOAP11:body use="literal"/> </wsdl:input> <wsdl:output name="getGreetingsResponse"> <SOAP11:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="HelloWorldService"> <wsdl:port name="HelloWorldPort" binding="tns:HelloWorldBinding"> <SOAP11:address location="http://192.168.247.1:8085/HelloWorldService"/> </wsdl:port> </wsdl:service> </wsdl:definitions>
