[xgws-user] Re: Huge Problem using wsa:Endpointreference
Shanmuga.MUHUNTHAN@fr.thalesgroup.com
Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com
Fri, 19 May 2006 11:34:32 +0200
thanks for your reply,
In fact I wanted to use JAXB2 (or at least DIGESTER). As I can understand, JAXB2 offers parsing + databinding (with XJC binding compiler).
But the problem is :
1. I don't know if jaxb2 can understand the soap syntax (complex syntax, multiple namespace, difference beetwen header-body...) and
2. I wonder whether jaxb2 can act as quickly as XPP + XMLInfosetBuilder + XMLBeans.
On the other hand I see two benefits : one package for all parsing purpose, and java classes generated by XJC are very simple compared to XMLBeans generated classes.
Do you think I can try to use JAXB2 with XSUL ?
Best regards
Shan
-----Message d'origine-----
De : Aleksander Slominski [mailto:aslom_at_cs.indiana.edu]
Envoyé : jeudi 18 mai 2006 19:24
À : Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com
Cc : xgws-user_at_cs.indiana.edu
Objet : Re: [xgws-user] Re: Huge Problem using wsa:Endpointreference
Shanmuga.MUHUNTHAN_at_fr.thalesgroup.com wrote:
> hi,
hi Shan,
>
> I have several questions concerning parsing soap message:
>
> 1. Where in XSUL, the soap message is parsed and converted to java
> object ?
those are two separate stages:
1) xml parsing and creation of some xml tree representation (it could be
partial tree with subtrees accessed as xml event streams)
2) (optional) databinding to convert xml tree/stream into Java objects.
currently XSUL has code for XmlBeans but other databindings could be added
for HTTP incoming connection XSUL classes (such as
HttpDynamicInfosetProcessor or HttpBasedServices) will typically check
content-type if it is XML and then parse it in XmlDocument/XmlElement
using pull parser and XmlInfosetBuilder to build xml tree (this could be
incrementally built tree but for small messages it is faster and smaller
memory footprint just to parse whole message than to do lazy building of
SOAP:Body - SOAP:Header must be fully parsed to enable header processing)
XML-Java databinding happens if you used a class that requests it. for
example SoapRpcReflectionBasedService allows to register converter for
databinding XML->Java and Java->XML and XWSIF code is driven by metadata
- if a java interface generated by xwsdl from a WSDL file has XmlBeans
derived types it will do automatic databinding or no databinding if
methods in the java interface uses XmlElement (see samples/ and tests/)
> 2. Why XSUL doesn't use package like JAXB or SAX to parse SOAP message ?
you could use JAXB - it is just a databinding but you will need to write
code to call XML<->Java transformation - see how XmlBeans is done in XSUL
SAX could be used to build XPP3 DOM (XmlElement) if you create another
implementation of XmlInfosetBuilder and add methods to take SAX stream
as input
> 3. Is it simple to isolate the parser of XSUL in order to replace it
> by an other one ?
yes - you would need to create your own implementation of
XmlInfosetBuilder - it uses XmlPull API interfaces so any XmlPull parser
implementation can be used. by extending XmlInfosetBuilder you could add
other ways to build xml tree,
i hope that addresses your questions.
best,
alek
>
>
> -----Message d'origine-----
> *De :* xgws-user-admin_at_cs.indiana.edu
> [mailto:xgws-user-admin_at_cs.indiana.edu]*De la part de* Aleksander
> Slominski
> *Envoyé :* jeudi 4 mai 2006 15:52
> *À :* Tobias Anstett
> *Cc :* xgws-user_at_cs.indiana.edu
> *Objet :* [xgws-user] Re: Huge Problem using wsa:Endpointreference
>
> hi Tobias,
>
> XWSIF has a very simple "parser" of XML Schemas that checks that
> input message has complex type with sequence of elements each of
> some type (<xsd:element name="name" type="whatever">) but it does
> not support much more than that. if you know exactly what you want
> to pass (for example you generated XML content directly or used a
> tool to convert XML schema into Java objects such as XML Beans).
>
> in your case i would just modify XSUL code to disable XWSIF checks
> (in particular make it not to call
> WSIFMessageElement.addPlaceholderForParameters) then pass your XML
> as WSIFMessage - you can cast WSIFMessage to XmlElement and put
> your XML content (as defined in XML schema).
>
> also if you could change WSDL to pass reference element with
> wsa:EndpointReference type it would just work i.e.:
> <xsd:element name="myRefWhatever" type="wsa:EndpointReference">
>
> let me know if you have more questions.
>
> best,
>
> alek
>
> Tobias Anstett wrote:
>>
>> Here is the Stacktrace:
>>
>> 0 [main] DEBUG iaas.swom.shared.gw.XSULInvoker -
>> executeRequestResponseOperation
>> 261 [main] DEBUG iaas.swom.shared.gw.XSULInvoker - creating
>> service...
>> 393 [main] DEBUG iaas.swom.shared.gw.XSULInvoker - resolving the
>> port and setting the operation to invoke...
>> 647 [main] DEBUG iaas.swom.shared.gw.XSULInvoker - creating the
>> input-, output- and fault messages for the invoked operation...
>> 920 [main] ERROR iaas.swom.shared.gw.XSULInvoker -
>> iaas.swom.shared.exception.UserException:
>> xsul.wsif.WSIFException: element ref='wsa:EndpointReference' must
>> be in the namespace http://saap.tc.iaas/wsdl/datatypes not
>> {http://schemas.xmlsoap.org/ws/2004/08/addressing}EndpointReference
>> <http://schemas.xmlsoap.org/ws/2004/08/addressing%7DEndpointReference>
>> (context: <xsd:sequence xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>> <xsd:element name="content1" type="xsd:string" />
>> <xsd:element name="content2" type="xsd:string" />
>> <xsd:element name="content3" type="xsd:string" />
>> <xsd:element ref="wsa:EndpointReference" />
>>
>> </xsd:sequence>)
>> iaas.swom.shared.exception.UserException:
>> xsul.wsif.WSIFException: element ref='wsa:EndpointReference' must
>> be in the namespace http://saap.tc.iaas/wsdl/datatypes not
>> {http://schemas.xmlsoap.org/ws/2004/08/addressing}EndpointReference
>> <http://schemas.xmlsoap.org/ws/2004/08/addressing%7DEndpointReference>
>> (context: <xsd:sequence xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>> <xsd:element name="content1" type="xsd:string" />
>> <xsd:element name="content2" type="xsd:string" />
>> <xsd:element name="content3" type="xsd:string" />
>>
>> <xsd:element ref="wsa:EndpointReference" />
>>
>> </xsd:sequence>)
>> at
>> iaas.swom.shared.gw.XSULInvoker.executeRequestResponseOperation(XSULInvoker.java:751)
>> at iaas.swom.shared.gw.XSULInvoker.runClient(XSULInvoker.java:133)
>> at iaas.swom.shared.gw.XSULInvoker.runClient(XSULInvoker.java:97)
>> at iaas.swom.shared.gw.Test.main(Test.java:36)
>> Caused by: xsul.wsif.WSIFException: element
>> ref='wsa:EndpointReference' must be in the namespace
>> http://saap.tc.iaas/wsdl/datatypes not
>> {http://schemas.xmlsoap.org/ws/2004/08/addressing}EndpointReference
>> <http://schemas.xmlsoap.org/ws/2004/08/addressing%7DEndpointReference>
>> (context: <xsd:sequence xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>> <xsd:element name="content1" type="xsd:string" />
>> <xsd:element name="content2" type="xsd:string" />
>> <xsd:element name="content3" type="xsd:string" />
>>
>> <xsd:element ref="wsa:EndpointReference" />
>>
>> </xsd:sequence>)
>> at
>> xsul.wsif.impl.WSIFMessageElement.addListOfElementNames(WSIFMessageElement.java:235)
>> at
>> xsul.wsif.impl.WSIFMessageElement.addPlaceholderForParameters(WSIFMessageElement.java:162)
>> at
>> xsul.wsif.impl.WSIFMessageElement.<init>(WSIFMessageElement.java:57)
>> at
>> xsul.wsif_xsul_soap_http.XsulSoapOperation.createInputMessage(XsulSoapOperation.java:132)
>> at
>> iaas.swom.shared.gw.XSULInvoker.executeRequestResponseOperation(XSULInvoker.java:377)
>> ... 3 more
>>
>>
>>
>>
>> Here is validated and 100% correct wsdl:
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> service location could not be reached from outside ! (our firewall)
>
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
The best way to predict the future is to invent it - Alan Kay