Jitendra Kotamraju wrote:
>> What I still don't get, when I use Endpoint.publish, JAX-WS verifies
>> if the given port and service names match the given WSDL. If they
>> don't match, it tries to generate a new WSDL. When I use the
>> InVmContainer instead, this verification is not happening and JAX-WS
>> does not try to generate new WSDL. Why is it different?
> All of them go through the same EndpointFactory, so I don't see why
> it is different. So something must be different(may be harness already
> done that)
I have a pretty good understanding of what is going on now. When we
deploy an application with e.g. the local transport, the
LocalTransportFactory is invoking the DeploymentDescriptorParser and
that one instantiates WSEndpoints with the service and port names
derived from the deployment descriptor. When I use Endpoint.publish for
the HTTP transport instead, WSEndpoint is instantiated with the service
and port names set to null and consequently the JAX-WS EndpointFactory
parses the WSDL, compares it with the settings in the endpoint
implementation class, finds a mismatch and rejects it.
I think there would be a few options to solve this:
1) The JavaSeContainer could do what the LocalTransportFactory is doing,
i.e. parse the deployment descriptor, extract the service and port names
and set them explicitly in the endpoint before publishing them. This is
fairly easy to implement with little changes to the test harness. The
disadvantage is that it creates a dependency from the test harness to
the JAX-WS RI because we need access to at least
com.sum.xml.ws.api.server.WSEndpoint.
1a) We could do a solution similar to 1, but put the JAX-WS RI dependent
parts into JAX-WS, similarly to what was done for the local transport.
2) Right now the JavaSeContainer uses the same
AbstractApplicationContainer.assembleWar() method that is used by the
other containers. This is a fairly bad match for the Java SE deployment
logic because it generates a lot of cruft like sun-jaxws.xml, web.xml,
etc. that is irrelevant to the Endpoint.publish interface. And the
Endpoint.publish interface has a constraint in that it can instantiate
only one service with one port at a time, which is not enforced by the
AbstractApplicationContainer and WAR classes. Those methods in WAR that
the JavaSeContainer could still utilize are package private
unfortunately. Making the code in AbstractApplicationContainer more
general-purpose and moving the WAR specific code into more suitable
classes is considerable work unfortunately.
Any ideas for more options or opinions on what I should be doing? I am
right now favoring option 1a.
Fabian