I have a legacy SOAP WS in my JAVA project (1.7) which is currently giving some trouble. In its WEB-INF/wsdl/*.wsdl file there is this block
<xsd:schema>
<xsd:import namespace="https://myUrl.com/" schemaLocation="myService_schema.xsd"/>
</xsd:schema>
right after its deployment, when i download its wsdl via wget I get the following
<xsd:schema xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="https://o2o-staging.beeweeb.com/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="https://myUrl.com/" schemaLocation="http://myUrl.com:443/service-ws/myService?xsd=myService_schema.xsd"/>
</xsd:schema>
as you can see the xsd import address https://myUrl.com becomes http://myUrl.com:443, thus making the service inaccessible as nginx complains with a 400 error: The plain HTTP request was sent to HTTPS port
I really did some searching and found no problem assimilated to this. Can somebody please explain to me what is going on, and how to possibly fix it? the namespace url https: //myUrl.com should really remain that way, and is it possible to avoi its becoming http: //myUrl.com:443 ?
My server is Jboss 7.1
For whom it might be helpful.
When a soap webservice is deployed, jboss re-processes whatever wsdl and xsd you have in your WEB-INF/wsdl. My problem was that in my standalone.xml I had an http connector, while I actually needed an https one.
so you need to
1) change your connector to https (or whatever it is you are yousing for your web-app
<connector name="http" protocol="HTTP/1.1" scheme="https" socket-binding="http"
secure="true" proxy-port="443"/>
2) add and explicit wsdl port in your standalone.xml
<subsystem xmlns="urn:jboss:domain:webservices:1.2">
<modify-wsdl-address>true</modify-wsdl-address>
<wsdl-host>jbossws.undefined.host</wsdl-host>
<wsdl-port>443</wsdl-port>
Related
Can any one please suggest how can I find wsdl version my web service is exposing -
snippet from wsdl -
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex"
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy"
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://tempuri.org/"
xmlns:wsa10="http://www.w3.org/2005/08/addressing"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
name="XXXService" targetNamespace="http://tempuri.org/">
I have gone through these web links -
https://coderanch.com/t/502335/certification/determine-wsdl-version
according to above post it's 1.2
whereas looking at this -
https://www.soapui.org/docs/soap-and-wsdl/working-with-wsdls/
SoapUI documentation says "SoapUI supports 1.1 version of the WSDL specification".
Because my wsdl loads successfully in SoapUI - could it be version 1.1?
So, I am not sure which version of wsdl (1.1/1.2/2.0) my web service is exposing.
Any suggestions please.
There are two WSDL versions: 1.1 and 2.0. A history of how these versions got to be can be found on the Wikipedia page for WSDL.
Also on that page it's a useful image of the differences between them and how to recognize the version you are dealing with:
The easiest way is to look at the root element in the XML:
if it's called <definitions> then it's a WSDL 1.1;
if it's called <description> then it's a WSDL 2.0;
Most of the WSDLs you will find out there will be version 1.1, but if the technology is newer, it might also be possible to retrieve a WSDL 2.0. See for example the answer on this post for more details about some conventions of retrieving a SOAP web service's WSDL if it provides one.
I was trying to implement an Web Service Consumer from a different tool in our company. So the admin of this tool gave me a WSDL-File to import into our IBM Notes database (Sadly I'm not allowed to post the WSDL file here).
Now, when I want to create the new Web Service
by clicking ok I get the following error message "The requested operation failed: Connection refused: connect":
So I checked if our firewall blocked this request from our Domino server to the Tool server, but there was no request at all. The firewall showed nothing, so it seemed, this request never got out from the Domino server.
Did anybody get a similar error or can tell me, where I can check why Domino seems to block this request?
We have other Webservices running, so it can't be a general issue.
Edit1: Imports done in the WSDL file
<wsdl:types>
<xsd:schema targetNamespace="http://Interflex.de/Imports">
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd0" namespace="http://Interflex.de" />
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Interflex.IF6040.ServiceLayer.PublishedServices" />
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd3" namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays" />
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd4" namespace="http://schemas.datacontract.org/2004/07/Interflex.IF6040.ServiceLayer.PublishedServices.SharedDataContracts" />
<xsd:import schemaLocation="http://192.168.102.242:6042/InterflexServices/IF6040Service?xsd=xsd5" namespace="http://schemas.datacontract.org/2004/07/Interflex.IF6040.Modules.Recording.PersonEvents.Global.EventProcessing" />
</xsd:schema>
</wsdl:types>
I've created a pass through proxy service on top on a endpoint and selected Specify Source URL in publish wsdl options. The endpoint references to xsd's in the wsdl definition. The proxy web service generated fines, but when trying to load this web service from a client (SOAP UI), it throws an error because of the way the xsd is referenced in the proxy service wsdl URL.
Sample of Actual web service with an xsd definition
<types>
<xsd:schema>
<xsd:import namespace="http://service.example.com/" schemaLocation="http://172.16.91.82:7001/DemoService/DemoService?xsd=1"/>
</xsd:schema>
</types>
Sample of the proxy service with a reference to schema.
<wsdl:types>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="unqualified">
<xsd:import namespace="http://service.example.com/" schemaLocation="SecuredServiceProxy?xsd=http://172.16.91.82:7001/DemoService/DemoService?xsd=1"/>
</xsd:schema>
</wsdl:types>
The client has a problem loading the schema location (which of course looks invalid)
1) I'm looking at a way to get rid of this.
2) This proxy service is intended to hide the actual service from the end user. The way the xsd schema is listed in proxy service wsdl definition, is leaking the actual endpoint information to the end user. Is there a way to avoid the xsd url displayed in the generated wsdl definition of proxy service ?
Thanks.
So you mean to say that your endpoint is the URL and your publish wsdl is also url? you can try specifying your publish wsdl as inline and you can create a .xsd file in ESB_Home which should contain the contents of your xsd URL. And then you can refrence your .xsd file by changing the location from url to simply the name of the xsd file present in your ESB_Home directory in your inline wsdl as :
<wsdl:types>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="unqualified">
<xsd:import namespace="http://service.example.com/" schemaLocation="DemoService.xsd"/>
</xsd:schema>
</wsdl:types>
Hope this works for you
If you need to hide to the actual service details from the end user, you can avoid publishing the WSDL in WSO2 ESB.
Then you will be invoke the Proxy Service defined in the ESB.
I hope this helps.
Thanks!
In spring file applicationConfig.xml, JAX-WS integration need some specific schemas.
I recently successfully use these declarations :
https://jax-ws.dev.java.net/spring/core.xsd
https jax-ws.dev.java.net/spring/servlet.xsd
[I must remove all url (except one) because it's my first question]
The file begins with those declarations :
<beans xmlns="http www.springframework.org/schema/beans"
xmlns:xsi="http www.w3.org/2001/XMLSchema-instance" xmlns:aop="http www.springframework.org/schema/aop"
xmlns:tx="http www.springframework.org/schema/tx" xmlns:context="http www.springframework.org/schema/context"
xmlns:ws="http jax-ws.dev.java.net/spring/core" xmlns:wss="http jax-ws.dev.java.net/spring/servlet"
xsi:schemaLocation="http www.springframework.org/schema/beans http www.springframework.org/schema/beans/spring-beans.xsd
http www.springframework.org/schema/aop http www.springframework.org/schema/aop/spring-aop.xsd
http www.springframework.org/schema/tx http www.springframework.org/schema/tx/spring-tx.xsd
http www.springframework.org/schema/context http www.springframework.org/schema/context/spring-context.xsd
http jax-ws.dev.java.net/spring/core https jax-ws.dev.java.net/spring/core.xsd
http jax-ws.dev.java.net/spring/servlet https jax-ws.dev.java.net/spring/servlet.xsd">
(...)
<ws:service id="myService" bean="#myWS" />
<wss:binding url="/services/myws" service="#myService" />
Now, a migration occurs for website jax-ws.dev.java.net. These files are not found and I have some errors under Tomcat and Eclipse :
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'https://jax-ws.dev.java.net/spring/core.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not .
Is there a solution or something to prevent this error ?
Thanks
Finaly I extract XSD from jaxws-spring-1.8.jar (lib for jax-ws to work with Spring).
I put these XSD under WEB-INF directory, just near applicationContext.xml.
I modify declaration of schema in this file with :
http://jax-ws.dev.java.net/spring/core classpath:spring-jax-ws-core.xsd
http://jax-ws.dev.java.net/spring/servlet classpath:spring-jax-ws-servlet.xsd
I have seen the solution here :
Spring schemaLocation fails when there is no internet connection
I suppose you're using maven for building? Try adding the dependency to the pom.xml
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
<version>2.1-1</version>
</dependency>
If you're not using maven, make sure you have jax-ws libs on your classpath.
http://java.net/projects/jax-ws
You don't need to extract the XSD from the jaxws-spring jar.
You just need to make sure the URL you use corresponds to that in the META-INF/spring.schemas file in the jar
They are defined as follows:
http\://jax-ws.dev.java.net/spring/core.xsd=spring-jax-ws-core.xsd
http\://jax-ws.dev.java.net/spring/servlet.xsd=spring-jax-ws-servlet.xsd
http\://jax-ws.dev.java.net/spring/local-transport.xsd=spring-jax-ws-local-transport.xsd
Think you just need to replace https with http. E.g:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ws="http://jax-ws.dev.java.net/spring/core"
xmlns:wss="http://jax-ws.dev.java.net/spring/servlet"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://jax-ws.dev.java.net/spring/core http://jax-ws.dev.java.net/spring/core.xsd
http://jax-ws.dev.java.net/spring/servlet http://jax-ws.dev.java.net/spring/servlet.xsd>
For more info on spring.schemas, see here
I am trying to resolve a problem we have using glassfish V2 to publish a simple web service using a plain UserNameToken for security reasons. Since we were using Netbeans 6.5 to archive this we were looking into this tutorial.
Therefore the following steps were done:
In our dev environment we installed the Sun Java(TM) System Access Manager and can administer this through the admin console as well as through the Netbeans IDE. All good. The example from the tutorial worked perfect so we thought we are in a good position to move on.
After changing the security options for our web service we published this on our test environment without any Netbeans installed.
After that the following steps were done:
deploying the service
configure the realm in Access Manager for the IP address
setup the expected user to access the web service.
When our partner is now accessing the web service the actual web service code is not accessed and we always find in the server logging that the security header was not understood.
This is the message we receive at the server:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-10034404">
<wsu:Created>2009-01-19T16:33:38.537Z</wsu:Created>
<wsu:Expires>2009-01-19T16:34:08.537Z</wsu:Expires></wsu:Timestamp><wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-10034094">
<wsse:Username>myUser</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">myPasswd</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
<wsa:MessageID soapenv:mustUnderstand="0">uuid:ecc3b150-e646-11dd-96e5-9f80a576275b</wsa:MessageID>
<wsa:To soapenv:mustUnderstand="0">http://62.154.241.166:8080/HTNGService/WebServiceForTrustService</wsa:To>
<wsa:Action soapenv:mustUnderstand="0">http://webservice.trustinternational.com/ws/services/Htng2ReservationService</wsa:Action>
<wsa:From xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" soapenv:mustUnderstand="0">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:From>
</soapenv:Header>
<soapenv:Body>
...
</soapenv:Body></soapenv:Envelope>
our wsit.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="WebServiceForTrustService" targetNamespace="http://wstrust/" xmlns:tns="http://wstrust/" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp1="http://www.w3.org/ns/ws-policy" xmlns:fi="http://java.sun.com/xml/ns/wsit/2006/09/policy/fastinfoset/service" xmlns:tcp="http://java.sun.com/xml/ns/wsit/2006/09/policy/soaptcp/service"
>
<message name="otaHotelResNotif"/>
<message name="otaHotelResNotifResponse"/>
<portType name="WebServiceForTrust">
<operation name="otaHotelResNotif">
<input message="tns:otaHotelResNotif"/>
<output message="tns:otaHotelResNotifResponse"/>
</operation>
</portType>
<binding name="WebServiceForTrustPortBinding" type="tns:WebServiceForTrust">
<wsp:PolicyReference URI="#WebServiceForTrustPortBindingPolicy"/>
<operation name="otaHotelResNotif">
<input/>
<output/>
</operation>
</binding>
<service name="WebServiceForTrustService">
<port name="WebServiceForTrustPort" binding="tns:WebServiceForTrustPortBinding"/>
</service>
<wsp:Policy wsu:Id="WebServiceForTrustPortBindingPolicy">
<wsp:ExactlyOne>
<wsp:All/>
</wsp:ExactlyOne>
</wsp:Policy>
</definitions>
Does anyone has any idea what configuration might be missing here?
We also realised that in the IDE after turning the security (AM security) on there was a file created under configuration files/ amserver called amconfig.xml.
This file we can't find on the webserver after deploying the service nor in the *.war nor under addons/amserver or so.
The file internally looks like:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:AMConfig xmlns:ns2="http://identity.netbeans.org/access_manager_config_1_0">
<ProviderConfig type="WSP" name="WebServiceForTrustService">
<SecurityMechanism uri="urn:sun:wss:security:null:UserNameToken-Plain"/>
</ProviderConfig>
</ns2:AMConfig>
since the information is already in sun-web.xml which is published on the server I think that should not be the problem but might be helpful for you.
since we worked further on the above here a few new things even if it isn't solved.
The example tutorial was rebuild and deployed on the test-server. Client and Server Test app. Both are working fine when started locally on the test-server.
If we configure how ever a client from remote to use the same web-service with the same security information, we find the same error like with our other application.
Therefore I assume it has something to do with the configurations o Access Manager, but no idea which one.
I hope that helps anyone to help me.
Thanks!