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}getGreetings

but failing as the operation is registered in the binding inside the Axis service model with the name

{http://helloworld/HelloWorldServiceComponent/$promoted$HelloWorldService}getGreetings

This 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}getGreetings

Anyone 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>




Reply via email to