|
Replies:
5
-
Last Post:
Sep 16, 2008 12:37 AM
by: duncant
|
|
|
|
|
|
|
Endpoint Address in Client with different transport than one in wsdl
Posted:
Jun 12, 2008 2:43 PM
|
|
|
I see that with jax-ws/metro, allows using different endpoint addresses through BindingProvider.ENDPOINT_ADDRESS_PROPERTY
((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "...");
But, it seems the endpoint address must have the same transport protocol as specified in the wsdl. If the endpoint transport protocol is changed then, we get a ClientTransportException.
Is there any work around this. See the use case below.
Here the wsdl's soap address location is specified as <soap:address location="http://servername/SanFrancisco-SimpleRoute/MapServer"/>
But the client code resets the endpoint address to a different transport protocol, which throws a runtime exception.
((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,"dcom://SanFrancisco-SimpleRoute/MapServer");
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.lang.NullPointerException
at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:131)
It seems the TransportFactory is looking for an Http Transport, which is wrong.
If i change the wsdl's soap address it works.
<soap:address location="dcom://SanFrancisco-SimpleRoute/MapServer"/>
Is there any better solution or am i missing any.
|
|
|
|
|
|
|
Re: Endpoint Address in Client with different transport than one in
wsdl
Posted:
Jun 13, 2008 2:46 PM
in response to: jos_thomas
|
|
|
metro@javadesktop.org wrote:
> I see that with jax-ws/metro, allows using different endpoint addresses through BindingProvider.ENDPOINT_ADDRESS_PROPERTY
> ((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "...");
>
> But, it seems the endpoint address must have the same transport protocol as specified in the wsdl. If the endpoint transport protocol is changed then, we get a ClientTransportException.
>
> Is there any work around this. See the use case below.
>
> Here the wsdl's soap address location is specified as <soap:address location="http://servername/SanFrancisco-SimpleRoute/MapServer"/>
> But the client code resets the endpoint address to a different transport protocol, which throws a runtime exception.
>
> ((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,"dcom://SanFrancisco-SimpleRoute/MapServer");
>
> com.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.lang.NullPointerException
> at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:131)
>
> It seems the TransportFactory is looking for an Http Transport, which is wrong.
>
> If i change the wsdl's soap address it works.
> <soap:address location="dcom://SanFrancisco-SimpleRoute/MapServer"/>
> Is there any better solution or am i missing any.
>
You are not missing anything. While creating the proxy, it uses port
address scheme to insert the corresponding transport tube in tubeline.
In this case, it is http, so HttpTransportPipe is inserted. But your
application changes to dcom via request context and http transport tube
doesn't support other protocols.
So how are you supporting dcom, have you written your own transport Tube
and plugging in ?
Based on that there are few options.
Jitu
> [Message sent by forum member 'jos_thomas' (jos_thomas)]
>
> http://forums.java.net/jive/thread.jspa?messageID=280078
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Endpoint Address in Client with different transport than one in
wsdl
Posted:
Sep 10, 2008 1:53 PM
in response to: Jitendra Kotamr...
|
|
|
I ran into similar problem, JAX-WS client retrieves the WSDL at runtime using
"Service.create(WSDL_location_URL) of java.net.URL type" with
endpointAddress different from the WSDL served web server. JAX-WS soap
runtime throws exception saying "Server not available" at to Web Service is
NOT running on that host.
To solve this, I used JAX-WS, "Service.create(QName serviceName)", and using
"addPort()" method on service instance to set the desired "endpointAddress"
at runtime.
Can anyone of you interpret the technical details and differences between
choosing "Service.create(WSDL_URL)" and "Service.create(QName serviceName)
in conjunction with using addPort()".
Which one is the most desired way ? Are there any implications of using
"addPort()" method ?
(Jitendra garu, take time to respond! I know you are the author of JAX-WS
RI).
-thanks,
Isharo.
Jitendra Kotamraju wrote:
>
> metro@javadesktop.org wrote:
>> I see that with jax-ws/metro, allows using different endpoint addresses
>> through BindingProvider.ENDPOINT_ADDRESS_PROPERTY
>> ((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
>> "...");
>>
>> But, it seems the endpoint address must have the same transport protocol
>> as specified in the wsdl. If the endpoint transport protocol is changed
>> then, we get a ClientTransportException.
>>
>> Is there any work around this. See the use case below.
>>
>> Here the wsdl's soap address location is specified as <soap:address
>> location="http://servername/SanFrancisco-SimpleRoute/MapServer"/>
>> But the client code resets the endpoint address to a different transport
>> protocol, which throws a runtime exception.
>>
>> ((BindingProvider)stub).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,"dcom://SanFrancisco-SimpleRoute/MapServer");
>>
>> com.sun.xml.ws.client.ClientTransportException: HTTP transport error:
>> java.lang.NullPointerException
>> at
>> com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:131)
>>
>> It seems the TransportFactory is looking for an Http Transport, which is
>> wrong.
>>
>> If i change the wsdl's soap address it works.
>> <soap:address
>> location="dcom://SanFrancisco-SimpleRoute/MapServer"/>
>> Is there any better solution or am i missing any.
>>
> You are not missing anything. While creating the proxy, it uses port
> address scheme to insert the corresponding transport tube in tubeline.
> In this case, it is http, so HttpTransportPipe is inserted. But your
> application changes to dcom via request context and http transport tube
> doesn't support other protocols.
>
> So how are you supporting dcom, have you written your own transport Tube
> and plugging in ?
>
> Based on that there are few options.
>
> Jitu
>> [Message sent by forum member 'jos_thomas' (jos_thomas)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=280078
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
>> For additional commands, e-mail: users-help@metro.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Endpoint-Address-in-Client-with-different-transport-than-one-in-wsdl-tp17810116p19422920.html
Sent from the Metro - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Endpoint Address in Client with different transport than one in
Posted:
Sep 16, 2008 12:37 AM
in response to: Isharo
|
|
|
Isharo wrote:
> I ran into similar problem, JAX-WS client retrieves
> the WSDL at runtime using
> "Service.create(WSDL_location_URL) of java.net.URL
> type" with
> endpointAddress different from the WSDL served web
> server. JAX-WS soap
> runtime throws exception saying "Server not
> available" at to Web Service is
> NOT running on that host.
> To solve this, I used JAX-WS, "Service.create(QName
> serviceName)", and using
> "addPort()" method on service instance to set the
> desired "endpointAddress"
> at runtime.
This would seem to be the way the JAX-WS designers intended it to work. I'm guessing that the solution that many people use (overriding the BindingProvider location) is something that the designers didn't really intend people to use. I don't know this for sure, but it just looks like a kluge - it seems the designers would have provided a much cleaner API if it was intended to be used this way.
>
> (Jitendra garu, take time to respond! I know you are
> the author of JAX-WS
> RI).
> -thanks,
> Isharo.
Yes, please! Some clarification on the best, most portable and extensible way to do this would be helpful!
Furthermore, if I have a UDDI registry, how should I write my code to use the registry to bind to the service at run-time, taking into account that the WSDL I used when I built my code may no longer be available at the same location when I actually run my code. Does anyone have any examples of this?
Thanks,
Duncan
|
|
|
|
|
|
|
|
|
Re: Endpoint Address in Client with different transport than one in wsdl
Posted:
Jun 13, 2008 5:45 PM
in response to: jos_thomas
|
|
|
Yes i have written a DCOMtransportTube and registered the DCOMTransportTubeFactory as a new transport in \META-INF\services\com.sun.xml.ws.api.pipe.TransportTubeFactory file.
DCOMtransportTube basically gets the soap request and streams it through a different channel.
|
|
|
|
|
|
|
|
|
Re: Endpoint Address in Client with different transport than one in wsdl
Posted:
Jun 17, 2008 2:54 PM
in response to: jos_thomas
|
|
|
If the scheme changes like this, it becomes tricky. Your factory won't
be that clean.
* If you are going to dcom for all the requests, your factory would give
DCOMtransportTube for all schemes(including http)
* But if you are going to use HTTP and DCOM with the same proxy, then your factory would return DCOMtransportTube
for dcom scheme, and DeferredTransportPipe for all other schemes. At present, DeferredTransportPipe is not for public usage. So its upto you.
To work cleanly in this situation, runtime should probably create DeferredTransportPipe by default. DeferredTransportPipe would consult TransportTubeFactory and delegate to the correct transport tube.
Jitu
--------------------
Unfortunately we need to support HTTP and DCOM with the same proxy (http is the default, which is also the scheme defined in the wsdl).
I removed the soap:address in the wsdl, this ensures that jax-ws runtime loads the DeferredTransportPipe, which allows me to configure the endpoint address through request context for HTTP or DCOM.
I am not sure if this is a correct usage.
Jos
-------------------------
if the WSDL contains
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
then also DeferredTransportPipe is used. wsgen generates this kind of
soap:address by default.
Jitu
----------------------------
|
|
|
|
|
java.net RSS
