You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Urciolo, Kevin" <Ke...@ngc.com> on 2008/04/28 19:12:38 UTC
MTOM WSDL For Gsoap and CXF
The GSoap examples for MTOM show a WSDL with the following:
<complexType name="DataType">
<sequence>
<element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute ref="xmime4:contentType" use="optional"/>
</complexType>
The CXF examples for MTOM show a WSDL with the following:
<complexType name="xRayType">
<sequence>
<element name="imageData" type="xsd:base64Binary"
xmime:expectedContentTypes="application/octet-stream"/>
</sequence>
</complexType>
I currently get the following error when attempting to build the GSOAP
example using CXF. Are these approaches to flagging the use of MTOM
compatible? Can the CXF following the GSoap approach? Or do I need to
have different WSDLs, one for GSOAP and one for CXF?
[java]
[java] WSDLToJava Error: Thrown by JAXB : undefined element
declaration 'xop:Include'
[java]
[java] org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
undefined element declaration 'xop:Include'
[java] at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error
(JAXBBindErrorListener.java:34)
[java] at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerIm
pl.java:245)
[java] at
com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.jav
a:61)
[java] at
com.sun.xml.xsom.impl.parser.ParserContext$2.error(ParserContext.java:18
8)
[java] at
com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.j
ava:166)
[java] at
com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.jav
a:103)
[java] at
com.sun.xml.xsom.impl.parser.DelayedRef.resolve(DelayedRef.java:91)
[java] at
com.sun.xml.xsom.impl.parser.DelayedRef.run(DelayedRef.java:66)
[java] at
com.sun.xml.xsom.impl.parser.ParserContext.getResult(ParserContext.java:
126)
[java] at
com.sun.xml.xsom.parser.XSOMParser.getResult(XSOMParser.java:172)
[java] at
com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:488)
[java] at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImp
l.java:197)
[java] at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(
JAXBDataBinding.java:209)
[java] at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJava
Container.java:531)
[java] at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai
ner.java:185)
[java] at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai
ner.java:231)
[java] at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:
83)
[java] at
org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:102)
[java] at
org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:171)
[java] Caused by: org.xml.sax.SAXParseException: undefined element
declaration 'xop:Include'
[java] at
com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.j
ava:162)
[java] ... 14 more
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
Dan,
I think that he started with Aegis and then later wandered to Metro
for comparison purposes, and I also think that there is indeed an
xmime:base64binary that I ran into when I was tweaking Aegis MTOM.
--benson
On Wed, May 21, 2008 at 5:11 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> On May 20, 2008, at 4:30 PM, GlennS wrote:
>>
>> Unforunately, all the Java tools I've run across do not understand this
>> (or
>> do not realize this request/response uses MTOM). In order to get the Java
>> WSDL parsers to correctly interpret this WSDL file I have to modify the
>> type
>> to:
>>
>> <complexType name="FileChunk">
>> <annotation>
>> <documentation>contains a MIME attachment</documentation>
>> </annotation>
>> <sequence>
>> <element name="chunk" type="xmime:base64Binary"
>> xmime:expectedContentType="application/octet-stream"/>
>> </sequence>
>> </complexType>
>>
>
> Actually, normally you would use:
> <element name="chunk" type="xdd:base64Binary"
> xmime:expectedContentType="application/octet-stream"/>
>
> and not put the base64Binary in the xmime ns, but it doesn't really matter.
>
>>
>> REQUEST
>> =======
>>
>> POST / HTTP/1.1
>> SOAPAction: ""
>> Accept: application/soap+xml, multipart/related, text/html, image/gif,
>> image/jpeg, *; q=.2, */*; q=.2
>> Content-Type:
>>
>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap+xml";action=""
>> User-Agent: Java/1.6.0_06
>> Host: 127.0.0.1:6667
>> Connection: keep-alive
>> Content-Length: 623
>>
>> --uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
>> Content-Type:
>> application/xop+xml;charset=utf-8;type="application/soap+xml"
>> Content-Transfer-Encoding: binary
>>
>> <?xml version="1.0" ?>
>> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
>> <S:Body>
>> <ns3:getFileChunk xmlns:ns5="http://www.w3.org/2004/08/xop/include"
>> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
>> xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
>> xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
>> <filename>dw.log</filename>
>> <offset>0</offset>
>> <length>100000</length>
>> </ns3:getFileChunk>
>> </S:Body>
>> </S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
>
> Which is completely correct and allowed.
>
>
>> Unfortunately, it doesn't appear the Metro client correctly parses the
>> returned file chunk. I get a chunk type back but it contains no data (and
>> there are no exceptions either). One thing to notice between the GSOAP
>> client call and the Metro client call is that the HTTP contentType for
>> GSOAP
>> request is:
>>
>> Content-Type: application/soap+xml; charset=utf-8
>>
>> And the contentType for the Metro call is:
>>
>> Content-Type:
>>
>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap+xml";action=""
>>
>> I'm no SOAP expert but this initially caused my GSOAP server problems
>> because it interprets the request as having an incoming MIME component.
>
> Well, the soap message itself is in a mime component. That's allowed.
>
>>
>> So, at this point I am stuck. I can't figure out how to force the Java
>> Metro
>> Client to consume the returned attachment. I'm not sure what it's looking
>> for in the stream or if I haven't enabled a particular option.
>>
>> Can anyone tell me what's going on here? It looks like (as far as MTOM/XOP
>> methods) are concerned, the GSOAP and the Java world are incompatible. My
>> other non-MTOM methods work fine. I just can't see how to get MTOM to work
>> between GSOAP and the Java toolkits.
>
> Well, I cannot really help too much with Metro. Have you tried CXF? If
> you have a server up and running someplace, I could potentially give it a
> quick try and see what happens.
>
>
> Dan
>
>
>
>> One more note: I can use the SoapUI tools with the GSOAP WSDL file to get
>> file chunks. Apparently this tool does not rely on an underlying toolkit
>> and
>> does the WSDL and request/response parsing itself.
>>
>> Any help or suggestions would be appreciated!!!!!
>>
>>
>>
>>
>> Benson Margulies-4 wrote:
>>>
>>> Perhaps more to the point, however, the error you sent indicates that
>>> your
>>> gsoap device is simply sending invalid XML. All the prefixes have to be
>>> defined, and the complaint is that 'xop:' is not defined. have you used
>>> logging to pull a complete copy of the XML off the wire?
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
Well, I went and read the gSoap traffic. I think I agree that the
explicit use of xop:Include is not MTOM, and not a common practice. I
don't see a good plan for adding this to CXF.
Re: MTOM WSDL For Gsoap and CXF
Posted by GlennS <GS...@harmanbecker.com>.
Sorry, but unfortunately it would be tough for me to post the entire WSDL
since this is a bit of proprietary, closed-door system. The pertinent parts
of it that I think you'd be interested in, however, are fairly
straightforward to re-create with GSOAP and soapcpp2.exe. Ultimately,
GSOAP's author didn't choose the same protocol/nomenclature as the rest of
the Java world for signaling MTOM attachments in the WSDL. I don't believe
his approach is wrong or strictly incorrect from a standards perspective
(although I'm no expert here), but apparently not what the Java WSDL
toolsmiths were expecting.
I've attached a condensed WSDL with putChunk/getChunk methods where the
"chunk" is an MTOM/XOP attachment. This is basically what I started with
before I started tweaking my definitions to make them Java "compliant". I
also have attached my GSOAP header file (.h) that is used (via soapcpp2.exe)
to generate the WSDL. I hope this is what you are asking for . . .
Glenn
Benson Margulies-4 wrote:
>
> I'd really like to deal with this more comprehensively.
>
> Could you possibly post the entire WSDL?
>
> On Thu, May 22, 2008 at 3:04 PM, GlennS <GS...@harmanbecker.com> wrote:
>>
>> I figured out how to work my GSOAP/Java mis-match problem after a lot of
>> effort and some helpful pointers along the way.
>>
>> The currently documented (in the GSOAP user's guide) approach to enable
>> attachments is to specify an attachment type in your service header file
>> (diag.h) that you run soapcpp2.exe . . .
>>
>> struct diag__FileChunk
>> { _xop__Include xop__Include;
>> @char* xmime4__contentType;
>> };
>>
>> Unfortunately, this generates the following complex type:
>>
>> <complexType name="FileChunk">
>> <annotation>
>> <documentation>contains a MIME attachment</documentation>
>> </annotation>
>> <sequence>
>> <element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
>> </sequence>
>> <attribute ref="xmime4:contentType" use="optional"/>
>> </complexType>
>>
>>
>> Unfortunately none of the Java client generators understand this.
>> Finally, I
>> found a solution (see the GSOAP forum if you're interested:
>> http://tech.groups.yahoo.com/group/gsoap/message/15680). You basically
>> have
>> to redefine your MTOM type in a manner better understood (expected) by
>> the
>> Java WSDL parsers.
>>
>> Thanks for the offer of help. Hopefully my problems are behind me now.
>>
>>
>>
>>
>> dkulp wrote:
>>>
>>>
>>> On May 20, 2008, at 4:30 PM, GlennS wrote:
>>>> Unforunately, all the Java tools I've run across do not understand
>>>> this (or
>>>> do not realize this request/response uses MTOM). In order to get the
>>>> Java
>>>> WSDL parsers to correctly interpret this WSDL file I have to modify
>>>> the type
>>>> to:
>>>>
>>>> <complexType name="FileChunk">
>>>> <annotation>
>>>> <documentation>contains a MIME attachment</documentation>
>>>> </annotation>
>>>> <sequence>
>>>> <element name="chunk" type="xmime:base64Binary"
>>>> xmime:expectedContentType="application/octet-stream"/>
>>>> </sequence>
>>>> </complexType>
>>>>
>>>
>>> Actually, normally you would use:
>>> <element name="chunk" type="xdd:base64Binary"
>>> xmime:expectedContentType="application/octet-stream"/>
>>>
>>> and not put the base64Binary in the xmime ns, but it doesn't really
>>> matter.
>>>
>>>>
>>>> REQUEST
>>>> =======
>>>>
>>>> POST / HTTP/1.1
>>>> SOAPAction: ""
>>>> Accept: application/soap+xml, multipart/related, text/html, image/gif,
>>>> image/jpeg, *; q=.2, */*; q=.2
>>>> Content-Type:
>>>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>>>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>>>> +xml";action=""
>>>> User-Agent: Java/1.6.0_06
>>>> Host: 127.0.0.1:6667
>>>> Connection: keep-alive
>>>> Content-Length: 623
>>>>
>>>> --uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
>>>> Content-Type: application/xop+xml;charset=utf-8;type="application/
>>>> soap+xml"
>>>> Content-Transfer-Encoding: binary
>>>>
>>>> <?xml version="1.0" ?>
>>>> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
>>>> <S:Body>
>>>> <ns3:getFileChunk
>>>> xmlns:ns5="http://www.w3.org/2004/08/xop/include
>>>> "
>>>> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
>>>> xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
>>>> xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
>>>> <filename>dw.log</filename>
>>>> <offset>0</offset>
>>>> <length>100000</length>
>>>> </ns3:getFileChunk>
>>>> </S:Body>
>>>> </S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
>>>
>>> Which is completely correct and allowed.
>>>
>>>
>>>> Unfortunately, it doesn't appear the Metro client correctly parses the
>>>> returned file chunk. I get a chunk type back but it contains no data
>>>> (and
>>>> there are no exceptions either). One thing to notice between the GSOAP
>>>> client call and the Metro client call is that the HTTP contentType
>>>> for GSOAP
>>>> request is:
>>>>
>>>> Content-Type: application/soap+xml; charset=utf-8
>>>>
>>>> And the contentType for the Metro call is:
>>>>
>>>> Content-Type:
>>>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>>>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>>>> +xml";action=""
>>>>
>>>> I'm no SOAP expert but this initially caused my GSOAP server problems
>>>> because it interprets the request as having an incoming MIME
>>>> component.
>>>
>>> Well, the soap message itself is in a mime component. That's allowed.
>>>
>>>>
>>>> So, at this point I am stuck. I can't figure out how to force the
>>>> Java Metro
>>>> Client to consume the returned attachment. I'm not sure what it's
>>>> looking
>>>> for in the stream or if I haven't enabled a particular option.
>>>>
>>>> Can anyone tell me what's going on here? It looks like (as far as
>>>> MTOM/XOP
>>>> methods) are concerned, the GSOAP and the Java world are
>>>> incompatible. My
>>>> other non-MTOM methods work fine. I just can't see how to get MTOM
>>>> to work
>>>> between GSOAP and the Java toolkits.
>>>
>>> Well, I cannot really help too much with Metro. Have you tried
>>> CXF? If you have a server up and running someplace, I could
>>> potentially give it a quick try and see what happens.
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>> One more note: I can use the SoapUI tools with the GSOAP WSDL file
>>>> to get
>>>> file chunks. Apparently this tool does not rely on an underlying
>>>> toolkit and
>>>> does the WSDL and request/response parsing itself.
>>>>
>>>> Any help or suggestions would be appreciated!!!!!
>>>>
>>>>
>>>>
>>>>
>>>> Benson Margulies-4 wrote:
>>>>>
>>>>> Perhaps more to the point, however, the error you sent indicates
>>>>> that your
>>>>> gsoap device is simply sending invalid XML. All the prefixes have
>>>>> to be
>>>>> defined, and the complaint is that 'xop:' is not defined. have you
>>>>> used
>>>>> logging to pull a complete copy of the XML off the wire?
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>> ---
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17411311.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>
>
http://www.nabble.com/file/p17489608/Headunit.h Headunit.h
http://www.nabble.com/file/p17489608/HeadunitRemoteServices.wsdl
HeadunitRemoteServices.wsdl
--
View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17489608.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
I'd really like to deal with this more comprehensively.
Could you possibly post the entire WSDL?
On Thu, May 22, 2008 at 3:04 PM, GlennS <GS...@harmanbecker.com> wrote:
>
> I figured out how to work my GSOAP/Java mis-match problem after a lot of
> effort and some helpful pointers along the way.
>
> The currently documented (in the GSOAP user's guide) approach to enable
> attachments is to specify an attachment type in your service header file
> (diag.h) that you run soapcpp2.exe . . .
>
> struct diag__FileChunk
> { _xop__Include xop__Include;
> @char* xmime4__contentType;
> };
>
> Unfortunately, this generates the following complex type:
>
> <complexType name="FileChunk">
> <annotation>
> <documentation>contains a MIME attachment</documentation>
> </annotation>
> <sequence>
> <element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
> </sequence>
> <attribute ref="xmime4:contentType" use="optional"/>
> </complexType>
>
>
> Unfortunately none of the Java client generators understand this. Finally, I
> found a solution (see the GSOAP forum if you're interested:
> http://tech.groups.yahoo.com/group/gsoap/message/15680). You basically have
> to redefine your MTOM type in a manner better understood (expected) by the
> Java WSDL parsers.
>
> Thanks for the offer of help. Hopefully my problems are behind me now.
>
>
>
>
> dkulp wrote:
>>
>>
>> On May 20, 2008, at 4:30 PM, GlennS wrote:
>>> Unforunately, all the Java tools I've run across do not understand
>>> this (or
>>> do not realize this request/response uses MTOM). In order to get the
>>> Java
>>> WSDL parsers to correctly interpret this WSDL file I have to modify
>>> the type
>>> to:
>>>
>>> <complexType name="FileChunk">
>>> <annotation>
>>> <documentation>contains a MIME attachment</documentation>
>>> </annotation>
>>> <sequence>
>>> <element name="chunk" type="xmime:base64Binary"
>>> xmime:expectedContentType="application/octet-stream"/>
>>> </sequence>
>>> </complexType>
>>>
>>
>> Actually, normally you would use:
>> <element name="chunk" type="xdd:base64Binary"
>> xmime:expectedContentType="application/octet-stream"/>
>>
>> and not put the base64Binary in the xmime ns, but it doesn't really
>> matter.
>>
>>>
>>> REQUEST
>>> =======
>>>
>>> POST / HTTP/1.1
>>> SOAPAction: ""
>>> Accept: application/soap+xml, multipart/related, text/html, image/gif,
>>> image/jpeg, *; q=.2, */*; q=.2
>>> Content-Type:
>>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>>> +xml";action=""
>>> User-Agent: Java/1.6.0_06
>>> Host: 127.0.0.1:6667
>>> Connection: keep-alive
>>> Content-Length: 623
>>>
>>> --uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
>>> Content-Type: application/xop+xml;charset=utf-8;type="application/
>>> soap+xml"
>>> Content-Transfer-Encoding: binary
>>>
>>> <?xml version="1.0" ?>
>>> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
>>> <S:Body>
>>> <ns3:getFileChunk
>>> xmlns:ns5="http://www.w3.org/2004/08/xop/include
>>> "
>>> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
>>> xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
>>> xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
>>> <filename>dw.log</filename>
>>> <offset>0</offset>
>>> <length>100000</length>
>>> </ns3:getFileChunk>
>>> </S:Body>
>>> </S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
>>
>> Which is completely correct and allowed.
>>
>>
>>> Unfortunately, it doesn't appear the Metro client correctly parses the
>>> returned file chunk. I get a chunk type back but it contains no data
>>> (and
>>> there are no exceptions either). One thing to notice between the GSOAP
>>> client call and the Metro client call is that the HTTP contentType
>>> for GSOAP
>>> request is:
>>>
>>> Content-Type: application/soap+xml; charset=utf-8
>>>
>>> And the contentType for the Metro call is:
>>>
>>> Content-Type:
>>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>>> +xml";action=""
>>>
>>> I'm no SOAP expert but this initially caused my GSOAP server problems
>>> because it interprets the request as having an incoming MIME
>>> component.
>>
>> Well, the soap message itself is in a mime component. That's allowed.
>>
>>>
>>> So, at this point I am stuck. I can't figure out how to force the
>>> Java Metro
>>> Client to consume the returned attachment. I'm not sure what it's
>>> looking
>>> for in the stream or if I haven't enabled a particular option.
>>>
>>> Can anyone tell me what's going on here? It looks like (as far as
>>> MTOM/XOP
>>> methods) are concerned, the GSOAP and the Java world are
>>> incompatible. My
>>> other non-MTOM methods work fine. I just can't see how to get MTOM
>>> to work
>>> between GSOAP and the Java toolkits.
>>
>> Well, I cannot really help too much with Metro. Have you tried
>> CXF? If you have a server up and running someplace, I could
>> potentially give it a quick try and see what happens.
>>
>>
>> Dan
>>
>>
>>
>>> One more note: I can use the SoapUI tools with the GSOAP WSDL file
>>> to get
>>> file chunks. Apparently this tool does not rely on an underlying
>>> toolkit and
>>> does the WSDL and request/response parsing itself.
>>>
>>> Any help or suggestions would be appreciated!!!!!
>>>
>>>
>>>
>>>
>>> Benson Margulies-4 wrote:
>>>>
>>>> Perhaps more to the point, however, the error you sent indicates
>>>> that your
>>>> gsoap device is simply sending invalid XML. All the prefixes have
>>>> to be
>>>> defined, and the complaint is that 'xop:' is not defined. have you
>>>> used
>>>> logging to pull a complete copy of the XML off the wire?
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>> ---
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17411311.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: MTOM WSDL For Gsoap and CXF
Posted by GlennS <GS...@harmanbecker.com>.
I figured out how to work my GSOAP/Java mis-match problem after a lot of
effort and some helpful pointers along the way.
The currently documented (in the GSOAP user's guide) approach to enable
attachments is to specify an attachment type in your service header file
(diag.h) that you run soapcpp2.exe . . .
struct diag__FileChunk
{ _xop__Include xop__Include;
@char* xmime4__contentType;
};
Unfortunately, this generates the following complex type:
<complexType name="FileChunk">
<annotation>
<documentation>contains a MIME attachment</documentation>
</annotation>
<sequence>
<element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute ref="xmime4:contentType" use="optional"/>
</complexType>
Unfortunately none of the Java client generators understand this. Finally, I
found a solution (see the GSOAP forum if you're interested:
http://tech.groups.yahoo.com/group/gsoap/message/15680). You basically have
to redefine your MTOM type in a manner better understood (expected) by the
Java WSDL parsers.
Thanks for the offer of help. Hopefully my problems are behind me now.
dkulp wrote:
>
>
> On May 20, 2008, at 4:30 PM, GlennS wrote:
>> Unforunately, all the Java tools I've run across do not understand
>> this (or
>> do not realize this request/response uses MTOM). In order to get the
>> Java
>> WSDL parsers to correctly interpret this WSDL file I have to modify
>> the type
>> to:
>>
>> <complexType name="FileChunk">
>> <annotation>
>> <documentation>contains a MIME attachment</documentation>
>> </annotation>
>> <sequence>
>> <element name="chunk" type="xmime:base64Binary"
>> xmime:expectedContentType="application/octet-stream"/>
>> </sequence>
>> </complexType>
>>
>
> Actually, normally you would use:
> <element name="chunk" type="xdd:base64Binary"
> xmime:expectedContentType="application/octet-stream"/>
>
> and not put the base64Binary in the xmime ns, but it doesn't really
> matter.
>
>>
>> REQUEST
>> =======
>>
>> POST / HTTP/1.1
>> SOAPAction: ""
>> Accept: application/soap+xml, multipart/related, text/html, image/gif,
>> image/jpeg, *; q=.2, */*; q=.2
>> Content-Type:
>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>> +xml";action=""
>> User-Agent: Java/1.6.0_06
>> Host: 127.0.0.1:6667
>> Connection: keep-alive
>> Content-Length: 623
>>
>> --uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
>> Content-Type: application/xop+xml;charset=utf-8;type="application/
>> soap+xml"
>> Content-Transfer-Encoding: binary
>>
>> <?xml version="1.0" ?>
>> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
>> <S:Body>
>> <ns3:getFileChunk
>> xmlns:ns5="http://www.w3.org/2004/08/xop/include
>> "
>> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
>> xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
>> xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
>> <filename>dw.log</filename>
>> <offset>0</offset>
>> <length>100000</length>
>> </ns3:getFileChunk>
>> </S:Body>
>> </S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
>
> Which is completely correct and allowed.
>
>
>> Unfortunately, it doesn't appear the Metro client correctly parses the
>> returned file chunk. I get a chunk type back but it contains no data
>> (and
>> there are no exceptions either). One thing to notice between the GSOAP
>> client call and the Metro client call is that the HTTP contentType
>> for GSOAP
>> request is:
>>
>> Content-Type: application/soap+xml; charset=utf-8
>>
>> And the contentType for the Metro call is:
>>
>> Content-Type:
>> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
>> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
>> +xml";action=""
>>
>> I'm no SOAP expert but this initially caused my GSOAP server problems
>> because it interprets the request as having an incoming MIME
>> component.
>
> Well, the soap message itself is in a mime component. That's allowed.
>
>>
>> So, at this point I am stuck. I can't figure out how to force the
>> Java Metro
>> Client to consume the returned attachment. I'm not sure what it's
>> looking
>> for in the stream or if I haven't enabled a particular option.
>>
>> Can anyone tell me what's going on here? It looks like (as far as
>> MTOM/XOP
>> methods) are concerned, the GSOAP and the Java world are
>> incompatible. My
>> other non-MTOM methods work fine. I just can't see how to get MTOM
>> to work
>> between GSOAP and the Java toolkits.
>
> Well, I cannot really help too much with Metro. Have you tried
> CXF? If you have a server up and running someplace, I could
> potentially give it a quick try and see what happens.
>
>
> Dan
>
>
>
>> One more note: I can use the SoapUI tools with the GSOAP WSDL file
>> to get
>> file chunks. Apparently this tool does not rely on an underlying
>> toolkit and
>> does the WSDL and request/response parsing itself.
>>
>> Any help or suggestions would be appreciated!!!!!
>>
>>
>>
>>
>> Benson Margulies-4 wrote:
>>>
>>> Perhaps more to the point, however, the error you sent indicates
>>> that your
>>> gsoap device is simply sending invalid XML. All the prefixes have
>>> to be
>>> defined, and the complaint is that 'xop:' is not defined. have you
>>> used
>>> logging to pull a complete copy of the XML off the wire?
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
> ---
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17411311.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: MTOM WSDL For Gsoap and CXF
Posted by Daniel Kulp <dk...@apache.org>.
On May 20, 2008, at 4:30 PM, GlennS wrote:
> Unforunately, all the Java tools I've run across do not understand
> this (or
> do not realize this request/response uses MTOM). In order to get the
> Java
> WSDL parsers to correctly interpret this WSDL file I have to modify
> the type
> to:
>
> <complexType name="FileChunk">
> <annotation>
> <documentation>contains a MIME attachment</documentation>
> </annotation>
> <sequence>
> <element name="chunk" type="xmime:base64Binary"
> xmime:expectedContentType="application/octet-stream"/>
> </sequence>
> </complexType>
>
Actually, normally you would use:
<element name="chunk" type="xdd:base64Binary"
xmime:expectedContentType="application/octet-stream"/>
and not put the base64Binary in the xmime ns, but it doesn't really
matter.
>
> REQUEST
> =======
>
> POST / HTTP/1.1
> SOAPAction: ""
> Accept: application/soap+xml, multipart/related, text/html, image/gif,
> image/jpeg, *; q=.2, */*; q=.2
> Content-Type:
> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
> +xml";action=""
> User-Agent: Java/1.6.0_06
> Host: 127.0.0.1:6667
> Connection: keep-alive
> Content-Length: 623
>
> --uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
> Content-Type: application/xop+xml;charset=utf-8;type="application/
> soap+xml"
> Content-Transfer-Encoding: binary
>
> <?xml version="1.0" ?>
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
> <S:Body>
> <ns3:getFileChunk xmlns:ns5="http://www.w3.org/2004/08/xop/include
> "
> xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
> xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
> xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
> <filename>dw.log</filename>
> <offset>0</offset>
> <length>100000</length>
> </ns3:getFileChunk>
> </S:Body>
> </S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
Which is completely correct and allowed.
> Unfortunately, it doesn't appear the Metro client correctly parses the
> returned file chunk. I get a chunk type back but it contains no data
> (and
> there are no exceptions either). One thing to notice between the GSOAP
> client call and the Metro client call is that the HTTP contentType
> for GSOAP
> request is:
>
> Content-Type: application/soap+xml; charset=utf-8
>
> And the contentType for the Metro call is:
>
> Content-Type:
> multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-
> d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap
> +xml";action=""
>
> I'm no SOAP expert but this initially caused my GSOAP server problems
> because it interprets the request as having an incoming MIME
> component.
Well, the soap message itself is in a mime component. That's allowed.
>
> So, at this point I am stuck. I can't figure out how to force the
> Java Metro
> Client to consume the returned attachment. I'm not sure what it's
> looking
> for in the stream or if I haven't enabled a particular option.
>
> Can anyone tell me what's going on here? It looks like (as far as
> MTOM/XOP
> methods) are concerned, the GSOAP and the Java world are
> incompatible. My
> other non-MTOM methods work fine. I just can't see how to get MTOM
> to work
> between GSOAP and the Java toolkits.
Well, I cannot really help too much with Metro. Have you tried
CXF? If you have a server up and running someplace, I could
potentially give it a quick try and see what happens.
Dan
> One more note: I can use the SoapUI tools with the GSOAP WSDL file
> to get
> file chunks. Apparently this tool does not rely on an underlying
> toolkit and
> does the WSDL and request/response parsing itself.
>
> Any help or suggestions would be appreciated!!!!!
>
>
>
>
> Benson Margulies-4 wrote:
>>
>> Perhaps more to the point, however, the error you sent indicates
>> that your
>> gsoap device is simply sending invalid XML. All the prefixes have
>> to be
>> defined, and the complaint is that 'xop:' is not defined. have you
>> used
>> logging to pull a complete copy of the XML off the wire?
>>
>>
>
> --
> View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
Could you possibly attach a complete test case to a JIRA, C++ or C
source and all?
I wrote code to make Aegis aware of the xmime:content-type stuff, but
I had nothing to test it against, since (as you've noticed) the Java
world is not very interested in this. I'd be willing to try to set
this up and shake it out.
Re: MTOM WSDL For Gsoap and CXF
Posted by GlennS <GS...@harmanbecker.com>.
I'm struggling with the same/similar problem using a GSOAP generated WSDL
file with any of the popular Java SOAP stacks (Metro, Axis2, XFire, CXF,
etc...). I have a very simple interface that attempts to retrieve a "chunk"
of a file from a service by specifying a filename, file offset, and length
parameter and expecting the "chunk" to be returned via MTOM.
The "chunk" type from the GSOAP WSDL is defined as so:
<complexType name="FileChunk">
<annotation>
<documentation>contains a MIME attachment</documentation>
</annotation>
<sequence>
<element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
</sequence>
<attribute ref="xmime:contentType" use="optional"/>
</complexType>
This works fine with a GSOAP client and server. A typical transaction (GSOAP
to GSOAP) looks like this (captured with TCPMon):
REQUEST
=======
POST / HTTP/1.1
Host: 127.0.0.1:6667
User-Agent: gSOAP/2.7
Content-Type: application/soap+xml; charset=utf-8
Transfer-Encoding: chunked
Connection: close
286
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xop="http://www.w3.org/2004/08/xop/include"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:hrs="urn:xmethods-HeadunitRemoteServices">
<SOAP-ENV:Body>
<hrs:getFileChunk>
<filename xsi:type="xsd:string">dw.log</filename>
<offset xsi:type="xsd:unsignedInt">0</offset>
<length xsi:type="xsd:unsignedInt">156</length>
</hrs:getFileChunk>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>0
RESPONSE
========
HTTP/1.1 200 OK
Server: gSOAP/2.7
Content-Type: multipart/related;
boundary="==MUVFrXVlfA8s6FhgPB4hEG/zRuy9vh7nEOLvCj2XgoLHFOAn4ccpjV+ozipy==";
type="application/xop+xml"; start="<SOAP-ENV:Envelope>";
start-info="application/soap+xml; charset=utf-8"Transfer-Encoding:
chunkedConnection: close
49C
--==MUVFrXVlfA8s6FhgPB4hEG/zRuy9vh7nEOLvCj2XgoLHFOAn4ccpjV+ozipy==
Content-Type: application/xop+xml; charset=utf-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID:
<SOAP-ENV:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xop="http://www.w3.org/2004/08/xop/include"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:hrs="urn:xmethods-HeadunitRemoteServices">
<SOAP-ENV:Body>
<hrs:getFileChunkResponse>
<return xsi:type="hrs:FileChunk">
<xop:Include href="cid:id1"/>
</return>
</hrs:getFileChunkResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>--==MUVFrXVlfA8s6FhgPB4hEG/zRuy9vh7nEOLvCj2XgoLHFOAn4ccpjV+ozipy==Content-Type:
*/*Content-Transfer-Encoding: binaryContent-ID:
<id1>NEW LOG13:05:20 03-12-2008ship dw20.exe 11.0.8160.0Exception
ModeNEW LOG13:06:45 03-12-2008ship dw20.exe 11.0.8160.0Exception
Mode--==MUVFrXVlfA8s6FhgPB4hEG/zRuy9vh7nEOLvCj2XgoLHFOAn4ccpjV+ozipy==--0
Unforunately, all the Java tools I've run across do not understand this (or
do not realize this request/response uses MTOM). In order to get the Java
WSDL parsers to correctly interpret this WSDL file I have to modify the type
to:
<complexType name="FileChunk">
<annotation>
<documentation>contains a MIME attachment</documentation>
</annotation>
<sequence>
<element name="chunk" type="xmime:base64Binary"
xmime:expectedContentType="application/octet-stream"/>
</sequence>
</complexType>
I created a Metro client for this WSDL using NetBeans. I also enabled MTOM
for the binding by calling:
headunitremoteservices.HeadunitRemoteServicesPort port =
service.getHeadunitRemoteServices();
javax.xml.ws.BindingProvider bp = (javax.xml.ws.BindingProvider) port;
javax.xml.ws.soap.SOAPBinding soapBinding = (javax.xml.ws.soap.SOAPBinding)
bp.getBinding();
soapBinding.setMTOMEnabled(true);
When I make the call I see this in TCPMon:
Metro - Call
=========
REQUEST
=======
POST / HTTP/1.1
SOAPAction: ""
Accept: application/soap+xml, multipart/related, text/html, image/gif,
image/jpeg, *; q=.2, */*; q=.2
Content-Type:
multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap+xml";action=""
User-Agent: Java/1.6.0_06
Host: 127.0.0.1:6667
Connection: keep-alive
Content-Length: 623
--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0
Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
Content-Transfer-Encoding: binary
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
<S:Body>
<ns3:getFileChunk xmlns:ns5="http://www.w3.org/2004/08/xop/include"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:ns3="urn:xmethods-HeadunitRemoteServices"
xmlns:ns1="http://www.w3.org/2003/05/soap-encoding">
<filename>dw.log</filename>
<offset>0</offset>
<length>100000</length>
</ns3:getFileChunk>
</S:Body>
</S:Envelope>--uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0--
RESPONSE
========
HTTP/1.1 200 OK
Server: gSOAP/2.7
Content-Type: multipart/related;
boundary="==eJwXq3I7ON+klwZbrIb8Zy2rwBgNOqWHSPVy1iARmQkRg61rZvwv6QBYJb0t==";
type="application/xop+xml"; start="<SOAP-ENV:Envelope>";
start-info="application/soap+xml; charset=utf-8"Transfer-Encoding:
chunkedConnection: close
49C
--==eJwXq3I7ON+klwZbrIb8Zy2rwBgNOqWHSPVy1iARmQkRg61rZvwv6QBYJb0t==
Content-Type: application/xop+xml; charset=utf-8;
type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID:
<SOAP-ENV:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xop="http://www.w3.org/2004/08/xop/include"
xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
xmlns:hrs="urn:xmethods-HeadunitRemoteServices">
<SOAP-ENV:Body>
<hrs:getFileChunkResponse>
<return xsi:type="hrs:FileChunk">
<xop:Include href="cid:id1"/>
</return>
</hrs:getFileChunkResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>--==eJwXq3I7ON+klwZbrIb8Zy2rwBgNOqWHSPVy1iARmQkRg61rZvwv6QBYJb0t==Content-Type:
*/*Content-Transfer-Encoding: binaryContent-ID:
<id1>NEW LOG13:05:20 03-12-2008ship dw20.exe 11.0.8160.0Exception
ModeNEW LOG13:06:45 03-12-2008ship dw20.exe 11.0.8160.0Exception
Mode--==eJwXq3I7ON+klwZbrIb8Zy2rwBgNOqWHSPVy1iARmQkRg61rZvwv6QBYJb0t==--
0
Unfortunately, it doesn't appear the Metro client correctly parses the
returned file chunk. I get a chunk type back but it contains no data (and
there are no exceptions either). One thing to notice between the GSOAP
client call and the Metro client call is that the HTTP contentType for GSOAP
request is:
Content-Type: application/soap+xml; charset=utf-8
And the contentType for the Metro call is:
Content-Type:
multipart/related;type="application/xop+xml";boundary="uuid:91fb86fe-d236-4c29-83aa-5f80ff2af4e0";start-info="application/soap+xml";action=""
I'm no SOAP expert but this initially caused my GSOAP server problems
because it interprets the request as having an incoming MIME component.
Previously I had call
soap_post_check_mime_attachments(mSoap);
in my GSoap C++ server so that my code explicitly handles attachments. Since
on this request I wasn't expecting an incoming attachment, it screwed up the
server. I commented out this line to let GSOAP automatically handle
attachments in order to continue testing.
So, at this point I am stuck. I can't figure out how to force the Java Metro
Client to consume the returned attachment. I'm not sure what it's looking
for in the stream or if I haven't enabled a particular option.
Can anyone tell me what's going on here? It looks like (as far as MTOM/XOP
methods) are concerned, the GSOAP and the Java world are incompatible. My
other non-MTOM methods work fine. I just can't see how to get MTOM to work
between GSOAP and the Java toolkits.
One more note: I can use the SoapUI tools with the GSOAP WSDL file to get
file chunks. Apparently this tool does not rely on an underlying toolkit and
does the WSDL and request/response parsing itself.
Any help or suggestions would be appreciated!!!!!
Benson Margulies-4 wrote:
>
> Perhaps more to the point, however, the error you sent indicates that your
> gsoap device is simply sending invalid XML. All the prefixes have to be
> defined, and the complaint is that 'xop:' is not defined. have you used
> logging to pull a complete copy of the XML off the wire?
>
>
--
View this message in context: http://www.nabble.com/MTOM-WSDL-For-Gsoap-and-CXF-tp16943667p17350144.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
Perhaps more to the point, however, the error you sent indicates that your
gsoap device is simply sending invalid XML. All the prefixes have to be
defined, and the complaint is that 'xop:' is not defined. have you used
logging to pull a complete copy of the XML off the wire?
Re: MTOM WSDL For Gsoap and CXF
Posted by Benson Margulies <bi...@gmail.com>.
Funny you should mention this. If the xmine4 namespace prefix is the 'xmime'
namespace, then CXF 2.1 with Aegis can be asked to use this. When I tried to
go here with JAXB, I think I got into a deep hole in the JAXB reference
implementation, and my CXF collegues were uncertain that anyone ever uses
this schema.
Can you tell the URI for 'xmime4' so that I can check?
On Mon, Apr 28, 2008 at 1:12 PM, Urciolo, Kevin <Ke...@ngc.com>
wrote:
> The GSoap examples for MTOM show a WSDL with the following:
>
> <complexType name="DataType">
> <sequence>
> <element ref="xop:Include" minOccurs="1" maxOccurs="1"/>
> </sequence>
> <attribute ref="xmime4:contentType" use="optional"/>
> </complexType>
>
> The CXF examples for MTOM show a WSDL with the following:
>
> <complexType name="xRayType">
> <sequence>
> <element name="imageData" type="xsd:base64Binary"
>
> xmime:expectedContentTypes="application/octet-stream"/>
> </sequence>
> </complexType>
>
> I currently get the following error when attempting to build the GSOAP
> example using CXF. Are these approaches to flagging the use of MTOM
> compatible? Can the CXF following the GSoap approach? Or do I need to
> have different WSDLs, one for GSOAP and one for CXF?
>
>
> [java]
> [java] WSDLToJava Error: Thrown by JAXB : undefined element
> declaration 'xop:Include'
> [java]
> [java] org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
> undefined element declaration 'xop:Include'
> [java] at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error
> (JAXBBindErrorListener.java:34)
> [java] at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerIm
> pl.java:245)
> [java] at
> com.sun.tools.xjc.util.ErrorReceiverFilter.error(ErrorReceiverFilter.jav
> a:61)
> [java] at
> com.sun.xml.xsom.impl.parser.ParserContext$2.error(ParserContext.java:18
> 8)
> [java] at
> com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.j
> ava:166)
> [java] at
> com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.jav
> a:103)
> [java] at
> com.sun.xml.xsom.impl.parser.DelayedRef.resolve(DelayedRef.java:91)
> [java] at
> com.sun.xml.xsom.impl.parser.DelayedRef.run(DelayedRef.java:66)
> [java] at
> com.sun.xml.xsom.impl.parser.ParserContext.getResult(ParserContext.java:
> 126)
> [java] at
> com.sun.xml.xsom.parser.XSOMParser.getResult(XSOMParser.java:172)
> [java] at
> com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:488)
> [java] at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImp
> l.java:197)
> [java] at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(
> JAXBDataBinding.java:209)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJava
> Container.java:531)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai
> ner.java:185)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContai
> ner.java:231)
> [java] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:
> 83)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:102)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:171)
> [java] Caused by: org.xml.sax.SAXParseException: undefined element
> declaration 'xop:Include'
> [java] at
> com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.j
> ava:162)
> [java] ... 14 more
>
>