CODEWITHSUNDEEP
javaweb-servicessoapwsdl
user3960875
user3960875

Reputation: 1005

WSDL to java fails to convert

I've tried almost all of the generators and they've failed to convert this wsdl to java classes.

Apache axis: {http://www.maaamet.ee/}featureNameType is referenced but not defined.

SoapUI, JBossWS and wsimport: 'kujuGeomeetriaType' is already defined

This is a public wsdl thus changing it is not an option, also since it's public and in every day use it must be valid. Also I found this online service http://easywsdl.com/ that is able to convert that wsdl to java, but it costs to convert (Free version creates all kind of crap and uses library that I don't want to include ksoap2-android)

Since I do not know much about wsdl-s anyone have an idea how to fix the conversion issue?

Upvotes: 1

Views: 187

Answers (1)

VGR
VGR

Reputation: 44414

since it's public and in every day use it must be valid.

No, it’s not. The Internet has tons of crap on it. Obviously, some tool somewhere is engaging in some XSD version of “quirks mode,” but just as a browser entering quirks mode to accept invalid HTML does not make the HTML valid, this schema is not valid regardless of the existence of sloppy tools which allow it. The difference is that XML is designed from its base for precise syntax and structure in order to eliminate mistakes.

Both http://www.maaamet.ee/schemas/xTeenused/aadress_types.xsd and http://www.maaamet.ee/schemas/xTeenused/maa_types.xsd are indirectly imported, and both define kujuGeomeetriaType in the "http://www.maaamet.ee/" namespace. This is a violation of the XSD specification, which states “no complex type definition can have the same name as another simple or complex type definition.”

Any other tools which accept a broken schema are themselves broken and wrong for accepting invalid input. I realize asking the owner of those schemas to fix them will probably accomplish nothing, but they should be held accountable all the same.

In terms of a practical solution, I would download all of the schemas (and all the schemas they reference, recursively), and make the necessary fixes to the local copies. I would then include and make use of all of those fixed versions in the application’s .jar. You will not only need to remove the duplicate definitions, you will need to alter the schemaLocation attributes in <include> and <import> elements to refer to relative URLs (and thus to the schemas inside your .jar).

Upvotes: 1

Related Questions