I have noticed something strange with the following cluster wide property setting service.wsdlQueryEnabled.
When service.wsdlQueryEnabled=true, i am not able to download wsdl and i am getting a 404 not found.
When service.wsdlQueryEnabled=false, i am able to retrieve wsdl document.
But as per the description i see in the documents, it should be working the other way? Gateway v8.1
Controls whether the download of WSDL using the "?wsdl" URL suffix is permitted. When enabled, the WSDL document can be downloaded using the resolution path of the service. Value is a Boolean.
For details, see WSDL URL by Resolution URI.
I was not able to reproduce this with Gateway 8.1. Do you see anything in the ssg logs? When set to true you should see something along these lines below. If your case is working in reverse I would expect a setting of false would produce these entries.
com.l7tech.server.WsdlFilter: Forwarding WSDL request to '/ssg/wsdl?uri=/uri'
A silly question, but are you hitting the same WSDL over the same port? I only ask because WSDL downloads can be enabled / disabled per port (via Manage listen ports).
What is the result of going directly to: https://<host>:<port>/ssg/wsdl with it set to True and False?
I was talking about querying the wsdl of exposed apis directly with the wsdl query url as resolution path, I thought the setting is applicable to that too.
Port has default settings and I did not see any log entry other than below.2017-02-08T14:22:11.582-0500 INFO 907 com.l7tech.server.admin: ClusterProperty #74d88f2733bdccf24940b91501e8dcb3 (service.wsdlQueryEnabled) updated (changed value)
Thanks & regards,Anand
Thanks Anand. I tested using the query URL as well: https://ssg.com:8443/soap/service.serviceAgent?wsdl
When set to true this works, when false it does not. When this is called it internally forwards to /ssg/wsdl
this is why I mentioned testing of that endpoint. It seems the forwarding endpoint is accessible regardless of the setting (true or false).
Though for your case I would still have expected to see some log entries from the WsdlProxyServlet.
If nobody else in the communities has other suggestions it may be worth opening a case so we can review further.