DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9717>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9717 wsdl2java doesn't seem to understand some of the basic schema types ------- Additional Comments From [EMAIL PROTECTED] 2002-06-26 14:24 ------- Axis *may* not be able to fully support data types where there is no corresponding Java data type. In particular, we are (currently) not able to round-trip certain data types. We are wrestling with the problem that if we map many of the XML Schema types to the same Java type (in this case, Date or Calendar), the WSDL generated from this code will use the default generic Schema type. For example, instead of gYearMonth, you will get xsd:dateTime back from the generated WSDL. I see two possible ways around this: 1. Map all the Schema types to whatever Java type will work (unsignedInt -> int, gYearMonth -> Calendar, etc). Require users to provide fixed WSDL when deploying the service if they need these types in Axis ?WSDL output. 2. Make Java2WSDL "WSDL aware", so meta data is generated in the Server classes indicating the Schema types of all method arguments and complex type member variables so no information is lost. Note: this wont work if you are starting from straight Java, unless the meta data is coded in to the beans/classes. This does not address the constraint problem, see bug 9966. Also note: I am adding code to skip processing the http://schemas.xmlsoap.org/soap/encoding/ import because out support for these types are 'built-in', we do not need to see the schema for them.
