Hello Pete,
>
> This still has the problem that ?wsdl would return the http specific
> WSDL, not the extra transport (I think). Also, the request would also
> be accepted over HTTP instead of just over the extra transport.
I think there is the way to return custom port URL, please look at
HttpAdapter.createPortAddressResolver() and how it is used. Seems
inheriting HttpAdapterList it's possible to make it.
As for publishing wsdl via custom transport - think it's really feature
we miss now. Think MEX should solve that problem, but so far it supports
just HTTP transport, but AFAIK there are plans to support custom ones.
WBR,
Alexey.
> Am I barking up the wrong tree here? Do I need to start from scratch
> and write my own application loading code to replace the RI code
> (something I would be reluctant to pursue for maintenance reasons)
> when deploying as a war?
>
> Once there are more transports being written this would seem to me to
> be a "normal" type of deployment (service not published over http but
> ?wsdl still works and returns non-http endpoint in port).
>
> FWIW, the way our application loading works is to look at the WSDL and
> see the transports to be supported (from the URL schemes). The call
> chain (tubes equivalent) is then created and linked from each endpoint
> instance created for each endpoint definition in the wsdl. The
> endpoints over which messages can arrive have no relation to how the
> app was deployed (other than integrating with the servlet endpoint
> processing when exposed over http). The wsdl is available over http in
> all cases with all defined endpoints in it.
>
> Or is this already possible and I just can't see it?
>
> Cheers
>
> Pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>