I have created an Ejb endpoint WebService (.EAR) using metro and glassfish 3.1.2(b5) .
The wsdl file is published and accessible via https .
I generated the client artifact from the secured url and when I Run the client I get this error (server side):
ATTENTION: Invalid request scheme for Endpoint my_web_service. Expected https . Received http
This how I configured the secure connexion:
<glassfish-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>my_web_service</ejb-name>
<webservice-endpoint>
<port-component-name>my_web_service</port-component-name>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</webservice-endpoint>
</ejb>
</enterprise-beans>
</glassfish-ejb-jar>
If I change the implementation to a servlet endpoint (.war) everything run ok so I think that I'm missing something in the configuration.
To make this work you need to update the bundled version of grizzly in glassfish to 1.9.55 .
Related
After installing WSO2EI-6.1.1 to migrate from my old WSO2DSS to EI, I was trying to setup a simple php wsdl soup client to call the "Version" service from php with a direct link to service wsdl and I'm getting the following error:
php code:
try {
$client = new SoapClient("http://server-ip:8280/services/Version?wsdl");
$response = $client->getVersion();
var_dump($response);
} catch (SoapFault $fault) {
echo $fault->getMessage();
}
error:
Fatal error: Maximum execution time of 120 seconds exceeded
Seems like the connection is timing out... I have tried to get the service wsdl with file_get_contents with the same result, timing out. well sometimes it works with a terrible loading time of like 90-100 seconds, but most of the times it times out.
$wsdl = file_get_contents("http://server-ip:8280/services/Version?wsdl");
var_dump($wsdl);
I have tested the link in browser and it is loading fine. Also tested with curl from linux command line and it loads fine there as well so the link is accessible.
curl -v http://server-ip:8280/services/Version?wsdl
So the timeout happens only when I try to retrieve the wsdl from within php. however if I download and save the wsdl file and pass the local xml file in php instead, then the service works fine and the version is fetched and displayed.
try {
$client = new SoapClient("Version.xml");
$response = $client->getVersion();
var_dump($response);
} catch (SoapFault $fault) {
echo $fault->getMessage();
}
So it seems like the problem is only fetching the wsdl directly from server in php and the rest of the communication between the server and the client is working fine.
after few hours searching I decided to try nhttp transport in transportReceiver configuration of axis2 instead of pass through transport and the problem is solved. however, reading the docs it is noted that the default transport is pass through and it is better in terms of performance compared to nhttp.
so is it a bug or something there causing the problem or am I doing something wrong and its possible to retrieve the wsdl directly from server within php while using the pass through transport?
Update:
when I use port numbers 9763 for http or 9443 for https instead of 8280 and 8243 to access services or service wsdl then I can access services or wsdl from php with no problems. So can anyone please explain to me whats the difference when using the port number 9763 or 8280 to access a service over http transport? Is it ok to use 9763 instead of 8280 to deal with services or to use 9443 instead of 8243? Is it still using the passthru transport when I use ports 9763 and 9443?
All WSO2 servers have two types of transports — servlet and passthrough (or nhttp). These are used for different purposes. Servlet transports are exposed over port 9443 and 9763 by default. This is the port used by admin services and the management console. The version service also uses the same port. For the services that you write and deploy, they are exposed over 8280 and 8243 ports. To answer your question, for this service you have to use 9763 or 9443 ports. And you will be accessing the Version service over servlet transport and not passthrough transport.
I have a WS client deployed in Websphere container under linux that successfully calls a WebService published by a different application (I used CXF implementation). When I try the same client in a Tomcat container under Windows it behaves differently: wireshark captures reveal:
before invoking the webservice call my client requests the WSDL from the server at URL A
the server redirects the client to a different URL B
the client gets the WSDL from URL B.
Since the WSDL has a reference to an XSD file, the client requests the XSD from URL B assuming that the redirection also applies to the XSD file
The server responds with a not found error and the communication fails
My questions are:
A) How can it be that the client assumes that the XSD is at URL B, but it is actually at URL A?
B) Why is it that the same client does not ask for the WSDL when running on Websphere under Linux and it does ask for it when running on Tomcat under Windows? Is there any way to prevent it from requesting the WSDL an thus avoid the redirection issue?
Thanks a lot in advance!!!
I have the same mule webservice application with 2 different versions deployed on the same mule server. Let's call it MuleApp.1.0 and MuleApp.1.1. The flow is as simple as the example of webservice flow on mulesoft website. Their wsdl urls are different as:
http://www.myhost.com:25101/MuleApp.1.0/Service?wsdl
http://www.myhost.com:25101/MuleApp.1.1/Service?wsdl
Both of them are working as expected when the other is not deploying on the mule server. The issue happens when I having both of them deployed on the same mule server like what I used to do in WebLogic. Now I am able to access MuleApp.1.1, but when I tried to access MuleApp.1.0, I got the error as below
07-Mar-2013:14:52:57.142 VWILVM3667 [MuleApp.1.1].connector.http.mule.default.receiver.03
WARN org.mule.transport.http.HttpMessageReceiver NA
No receiver found with secondary lookup on connector: connector.http.mule.default with URI key: http://www.myhost.com:25101/MuleApp.1.0/Service
This is supposed to be a very common versionning case. What did I miss in my config?
You can't have two different applications sharing the same HTTP port in the same Mule instance.
So what probably happens is that MuleApp.1.0 doesn't deploy properly (check the logs), which is why there is no endpoint listening on /MuleApp.1.0.
Either:
Use a different port in the two apps,
Put both flows in a single app.
Create a frontal app that listens on port 25101 and both /MuleApp.1.0 and /MuleApp.1.1 paths and that dispatches requests to MuleApp.1.0 and MuleApp.1.1 on private ports (say 25102 and 25103).
I finally deployed my application on tomcat, and replaced http inbound endpoint with servlet inbound endpoint. I configure the web.xml with servlet class org.mule.transport.servlet.MuleReceiverServlet. Now I am able to deploy multiple applications on the same port.
I am getting the below exception when I invoke a jax ws webservice from my application deployed in WebSphere Application Server 6.1
SSL HANDSHAKE FAILURE: A signer with SubjectDN "CN=yyy.com, OU=For Intranet Use Only, OU=Web Hosting, O=xx, L=xx, ST=xx, C=xx" was sent from target host:port "*:9445". The signer may need to be added to local trust store "F://../trust.p12" . The extended error message from the SSL handshake exception is: "No trusted certificate found".
The enpoint url has https.
With the same enpoint url I am able to get a response from SOAP UI(Tool) without any certificate configuration etc..
Could you help me on this ?
I finally was able to fix this small issue.The Server certificate needs to be added to the websphere appserver truststore.This can be done from the admin console of websphere by providing the server domain and port.
I have created an Axis2 web service from Netbeans and deployed it successfully in Tomcat 6 on my web server.
When I use for instance SoapUI or Taverna to consume the web service, the server offers both HTTP and HTTPS methods to invoke it. However, using the HTTPS method renders a 404 error. (Probably because there is a server admin panel running on port 8443, but that doesn't matter right now.)
The problem is that my web service clients default to using the HTTPS service. I figured the simplest thing I could do to get the basic service to work, would be to disable the HTTPS endpoint, as the HTTP version runs flawlessly and I don't need the added security. But now I've spent hours on finding out how to do that, without success. The WSDL returned by Axis2 contains entries for HttpsSoap11Endpoint but the WSDL that's bundled in my .AAR file after the build does not.
Does anybody know how to make Axis2 offer just HTTP endpoints?
In axis2.xml, comment out the https transport receiver to disable the HTTPS endpoint.