Aegis, for example, creates XML Schema that includes all the xmime/xop stuff for MTOM. There's no reason why other schemas cannot as well, is there?
On Fri, May 7, 2010 at 3:28 PM, Jeffrey Knight <[email protected]> wrote: > I'm using CFX 2.2.7. I'm ok on on the CFX side. > > It's really the XML Schema validation side that I'm struggling with, > because this XML > <ns:imageData> > <inc:Include href="cid:143666242607" > xmlns:inc="http://www.w3.org/2004/08/xop/include"/> > </ns:imageData> > > just isn't valid for the XSD with that specifies > <xs:element name="imageData" type="xs:base64Binary" > xmime:expectedContentTypes="application/octet-stream"/> ... > > We have DataPower in front of the server running CXF (on WebSphere) > and the WSDL from that CFX uses needs to also reside on DataPower. So > the problem is actually at the DataPower level, rather than CXF. > Maybe there's an XML/XSD specific mailing list I can check with (or > stackoverflow), but I'm sure this comes up in the context of CXF quite > frequently. > > -Jeff > > On Fri, May 7, 2010 at 2:03 PM, Daniel Kulp <[email protected]> wrote: >> >> What version of CXF? I kind of hacked a workaround for this a little while >> ago. Recent versions of CXF should handle this automatically. >> >> Dan >> >> >> On Friday 07 May 2010 11:24:26 am Jeffrey Knight wrote: >>> Hello >>> >>> This is somewhat less of a CXF question and more a general MTOM/Base64 >>> XSD validation question. >>> >>> I have an mtom-enabled cxf web service. The base64Binary portion of me >>> XSD looks like this: >>> >>> XSD: ... <xs:element name="imageData" type="xs:base64Binary" >>> xmime:expectedContentTypes="application/octet-stream"/> ... >>> >>> In order to ensure MTOM works and incoming requests are validated >>> against the XSD, I have my jaxws:endpoint properties configured with: >>> <entry key="mtom-enabled" value="true"/> >>> <entry key="schema-validation-enabled" value="true" /> >>> >>> The following XML request from a client is valid against the XSD above: >>> >>> Soap Request XML: ... >>> <ns:imageData>base-64-encoded-file-here</ns:imageData> ... >>> >>> So far so good. >>> >>> But when I enable MTOM in a client, it correctly adds the href/cid and >>> sends: Soap Request XML: >>> ... >>> <ns:imageData> >>> <inc:Include href="cid:143666242607" >>> xmlns:inc="http://www.w3.org/2004/08/xop/include"/> >>> </ns:imageData> >>> ... >>> >>> This rightly fails XSD validation with: >>> Element 'imageData' must have no element >>> (or similarly just using XMLBeans to test validation: >>> cvc-complex-type.2.4b: Element not allowed: >>> incl...@http://www.w3.org/2004/08/xop/include in element >>> imaged...@urn://my.urn.here) >>> >>> I'd like to have my XSD optionally allow MTOM "<inc:include.." piece, >>> so clients can either send either base64 or MTOM (their choice) and >>> have both pass XSD validation. >>> >>> But if I try to define an child element of my <ns:imageData>, I run >>> into the issue that it's "Illegal to define a nested type when a type >>> attribute is specified". >>> >>> If I disable XSD validation this all works. And I can hack around this >>> with a custom jaxb-validation-event-handler that ignores this >>> particular error, but I need a WSDL with valid XSD's for various ESB >>> deployment reasons. >>> >>> Has anyone run into this before? It's basically the same thing as >>> described here: >>> http://stackoverflow.com/questions/749784/wsdl-validation-error-when-using- >>> mtom >>> >>> -Jeff >> >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> >
