> Regarding the second issue, I am somewhat unclear how JAX-WS deals
> with providers vs ordinary web services. When I run the service (with
> a SOAP 1.2 binding) as a provider with WSDL and the service port and
> service names don't exactly match the WSDL names, JAX-WS bails out:
JAX-WS doesn't generate WSDL for Provider endpoints. So the following
exception may be for SEI based endpoints.
>
> com.sun.xml.ws.server.ServerRtException: Cannot generate WSDL for
> binding "http://www.w3.org/2003/05/soap/bindings/HTTP/"
> at
> com.sun.xml.ws.server.EndpointFactory.generateWSDL(EndpointFactory.java:415)
>
> at
> com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:196)
>
> at
> com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
For the above binding id, we cannot generate WSDL. You need to use
X_SOAP12HTTP_BINDING which is
"
http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"
>
> This is because JAX-WS is examining the WSDL, doesn't find a
> wsdl:service/port that matches the annotations in the service class,
> tries to generate WSDL and fails, because JAX-WS does not allow the
> generation of WSDL for the regular SOAP 1.2 binding. So far so good
> and I can deal with that by explicitly setting the wsdl:port and
> wsdl:service names with the WebService annotation. However, what I
> cannot explain is why this test with bogus port and service names is
> running through when I run it as an ordinary web service instead of a
May be harness generated a sun-jaxws.xml that overrides the annotation
based service and port names.
> provider? Does JAX-WS not compare the names set in the WSDL with what
> is set in the service?
yes. DD values override what is set on the annotation.
Jitu