简体   繁体   中英

WSDL import location using CXF and Tomcat

I am using CXF to generate WSDL's with Java and Tomcat as the application container. I am having an issue where the wsdl import location is not including the ssl link version. Here's the example:

<wsdl:import location="http://api.test.com/soap_admin?wsdl=AdminApi.wsdl" namespace="http://admin.test.com"></wsdl:import>

Should be (I know how to change the namespace value, just not location value):

<wsdl:import location="https://api.test.com/soap_admin?wsdl=AdminApi.wsdl" namespace="https://admin.test.com"></wsdl:import>

I also have a load balancer in front that is doing the SSL authentication and then it redirects to one of 2 different servers behind it. The WSDL is abled to be pulled no problem but just for consistency sake would like the location field to have the https in it.

Also I have seen a number of other problems on stack overflow that are semi the same thing but nothing has been exact. For example this link:

specify location in wsdl:import

But this is done on the WCF stack and is not what I am using at all. Also my gut tells me its a simple CXF or Tomcat config change. Also it would be nice for it to be dynamic to the point if I have it deployed on one of my dev servers that doesn't use SSL to not include the https.

Please advise!

I always try to keep local copies of the WSDL documents that I generate source code from, so that my build doesn't fail if a service happens to be transiently down. Yes, this has the down-side of meaning that the service location isn't correct, but that's pretty easy to fix by setting properties on the Server object, just like you'd do for setting a username and password. (Of course, if there were service API changes I'd likely need to change rather a lot of code anyway.) Once you're keeping a local copy, just set <wsdl:import location=… /> to the local path (using a text editor!); the location there won't be used after code generation is done.

Trying to generate source off of a live service is a neat idea, except that it really sucks for most deployments. Make a copy, boost your build reliability, worry less (or at least about other things).

Fixed this by adding another connector port to my server.xml config for tomcat 7:

<Connector port="8081" maxHttpHeaderSize="8192"
maxThreads="300" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" scheme="https" proxyPort="443" proxyName="your.frontend.address" disableUploadTimeout="true" />

Also @Donal, I essentially define two versions of how to connect to this tomcat now. The code I just listed I point my load balancer at, then for internal user I still have an 8080 connector port defined. Obviously can adjust that config to whatever suits your need. Your solution certainly works, but still have fairly immature product and I don't want to have to do that all of the time.

I originally thought this was a CXF issue, but just turns out its a tomcat config change.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM