Since I don't think anyone responded to Sam on this.
1. WSDL2Java clearly has a bug here. It should be fixed, but I don't know where 2. Adding a MIME_OCTETSTREAM return value from that utility function sounds right 3. This is just missing from WSDL2Java since the person who did DIME work on the engine did nothing to WSDL2Java and I assume Russell, who did WSDL2Java attachment work, was working from the WSDL spec (which DIME isn't a part of). We need new implementation here. -- Tom Jordahl Macromedia Server Development -----Original Message----- From: Sam Ruby [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 10:48 PM To: [EMAIL PROTECTED] Subject: WSDL/Attachments issues/questions Looking at the 4 WSDL documents defined as part of Group G at http://www.whitemesa.net/r4/interop4.html, I've encountered the following: 1) The WSDL appears to correctly specify xsd:base64Binary. Somehow, internal to WSDL2Java, this gets mapped to soap-enc:base64Binary, which does not exist. There are all sorts of places where this could be intercepted and converted into soap-enc:base64. Anybody have a preference? 2) wsdl.toJava.Utils.getMIMETypeQName doesn't handle the case where the mimeName is application/octetstream, and whenever this routine returns null wsdl2Java ends up with a NPE. Mapping it to Constants.MIME_PLAINTEXT does get WSDL2Java to process these WSDLs successfully, but the corect fix is probably to define a MIME_OCTETSTREAM. 3) I see nothing in WSDL2Java which detects dime:message, and sets call.ATTACHMENT_ENCAPSULATION_FORMAT appropriately. While this seems straightforward enough, I need to figure out what open vs closed for message layout means to Axis. - Sam Ruby
