Forum Discussion
eam
New Member
It is a shame to see it's not yet fixed in 2019, even though this is clearly a bug, as the number keeps increasing it could have been used like Service_<n+1> and not like Service_1_..._n_<n+1>
In my case it is even worse, as we got a wsdl with xsds that total up to 140 something files, and SOAP UI could not write those files to the disk, as windows won't let file names longer than 250 something.
I found these lines in the code which creates the filenames in com.eviware.soapui.impl.support.definition.export.AbstractDefinitionExporter class:
for(int cnt = 1; urlToFileMap.containsValue(fileName); cnt++) { ix = fileName.lastIndexOf('.'); fileName = (new StringBuilder()).append(fileName.substring(0, ix)).append("_").append(cnt).append(fileName.substring(ix)).toString(); }
and changed it to:
for(int cnt = 1; urlToFileMap.containsValue(fileName); cnt++) { ix = fileName.lastIndexOf('.'); int iy = fileName.lastIndexOf("_"); if (iy == -1) iy = ix; fileName = (new StringBuilder()).append(fileName.substring(0, iy)).append("_").append(cnt).append(fileName.substring(ix)).toString(); }
After adding this file on the classpath and doing the same export, the result looks better:
Service.wsdl Service.xsd Service_1.wsdl Service_1.xsd Service_2.wsdl Service_2.xsd Service_3.xsd Service_4.xsd Service_5.xsd ...
Related Content
- 2 years ago
- 2 years ago
- 2 years ago
- 2 years ago
Recent Discussions
- 15 years ago