Peter Hendry wrote::
> I'm trying to get to grips with writing a transport for the RI. Seems
> simple enough in a standalone context but I am a bit lost when deploying
> to a servlet.
>
> My requirements are
>
> 1) deploy as servlet (war with sun-jaxws.xml)
> 2) service exposed over non-http transport(s) only
> 3) WSDL is exposed over ?wsdl as normal and has correct non-http
> endpoint in it's port
>
> Say I want to expose a service over JMS (not necessarily using the
> jms-jaxws-transport implementation in its current form). I would like to
> deploy this as a war as normal with a sun-jaxws.jar and use the
> "url-pattern" to specify the transport url ("x-jms:...") - or some other
> attribute (transport-url for example).
sun-jaxws.xml currently lacks the extensibility that are needed deploy
custom transports from extensions. What we are doing right now is to use
Spring as the primary deployment mechanism, not sun-jaxws.xml.
The SMTP transport we are implementing right now does just that.
Does this work with you?
> One approach that may get me part of the way would be to extend the
> WSServletContextListener class (ah, if only it were not final) so that
> after it returns from setting up the endpoints for HTTP (specifically
> ServletAdapter) I could then parse the sun-jaxws.xml file again looking
> for a new attribute ("transport-url") on <endpoint> elements and then
> setup new transport listeners based on these endpoints (is there a
> schema for sun-jaxws.xml that I would then be violating? The code
> doesn't appear to validate there are no extra attributes).
>
> 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.
>
> 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
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com