Hi Marius
Yes, you can intercept the XML on the client side using interceptors.
It looks like this is missing from the documentation. The (poorly named)
HTTP Servlet Interceptor also includes client side interception. See
the lines in bold :
private HelloClient(String location) throws JiBXException {
m_location = location;
m_fact = BindingDirectory.getFactory(Greetee.class);
* m_requestBaos = new ByteArrayOutputStream(4096);
m_responseBaos = new ByteArrayOutputStream(4096);
m_outInterceptor = new
CopiedOutputStreamInterceptor(m_requestBaos);
m_inInterceptor = new CopiedInputStreamInterceptor(m_responseBaos);
* }
private Welcome sayHello(Greetee s) throws WsException, IOException {
SoapClient client = new SoapClient(m_location, m_fact);
* TransportOptions transportOptions =
TransportDirectory.newTransportOptions(m_location);
if (transportOptions instanceof OutputStreamInterceptable) {
((OutputStreamInterceptable)transportOptions).setOutputStreamInterceptor(m_outInterceptor);
}
if (transportOptions instanceof InputStreamInterceptable) {
((InputStreamInterceptable)transportOptions).setInputStreamInterceptor(m_inInterceptor);
}
client.setTransportOptions(transportOptions);
*
Welcome welcome = (Welcome) client.call(s);
* System.out.println("Request is " + m_requestBaos.toString());
System.out.println("Response is " + m_responseBaos.toString());
* return welcome;
}
It appears that your SOAP fault message is not obeying the schema
(http://schemas.xmlsoap.org/soap/envelope/), which defines:
<xs:complexType name="Fault" final="extension">
<xs:sequence>
<xs:element name="faultcode" type="xs:QName"/>
<xs:element name="faultstring" type="xs:string"/>
<xs:element name="faultactor" type="xs:anyURI" minOccurs="0"/>
<xs:element name="detail" type="tns:detail" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
The detail and faultactor in your SOAP fault are reversed. (faultactor
is also defined as a URI, but we don't enforce that).
The best course of action would be to modify the server to generate
correct SOAP faults. We don't have any extension points in JiBX/WS that
would allow invalid SOAP fault structures to be parsed. You could also
look at creating a servlet filter that would correct the fault structure
before it got to JiBX/WS.
For the 2nd case, it looks like the ignore or exclude code generation
customizations would work, though I'm no expert on codegen (see
http://jibx.sourceforge.net/fromschema/codegen-customs.html#ignore).
Yes I think this would mean making a copy of jibx-ota and rebuilding it.
Can anyone else comment on this?
cheers
Nigel
On 15/04/11 03:53, Marius-Cristian Vasilescu wrote:
Hi,
I've started using jibx-ota (OSGi pre-packaged) and I'm really happy
with it, but my Java skills aren't very good atm so I would appreciate
a little bit of help.
First of all is there any way to intercept the XML (inbound and
outbound) messages when soapClient.call() is called? Especially when
it's over a secure connection.
I've ran into two common errors, but I couldn't find a solution. The
first one occurs when I get a fault message because of the extra
"faultactor" tag. Should I add something for fault handling? Adding
"soapClient.addInFaultDetailsHandler(new ExceptionReader());" didn't help.
org.jibx.ws.WsException: Error reading end of fault.
Root cause: org.jibx.runtime.JiBXException: Expected
"{http://schemas.xmlsoap.org/soap/envelope/}Fault
<http://schemas.xmlsoap.org/soap/envelope/%7DFault>" end tag, found
"faultactor" start tag
.....
<soap:Body>
<soap:Fault>
<faultcode>soap:Client.3100</faultcode>
<faultstring>Authentication Error</faultstring>
<detail>
<text>Invalid or missing credentials</text>
</detail>
<faultactor>security_manager</faultactor>
</soap:Fault>
</soap:Body>
....
In the second case there is an error because of the missing "EchoData"
tag, just after <Success/>. I think OTA specifications require
EchoData or at least the OSGi built requires it, but the server
response doesn't contain the tag. Is there any way to handle such
errors without changing binding.xml and recompile everything?
..because there are so many dependencies. What would you recommend?
org.jibx.ws.WsException: Error in unmarshalling.
Root cause: org.jibx.runtime.JiBXException: Expected
"{http://www.opentravel.org/OTA/2003/05}EchoData
<http://www.opentravel.org/OTA/2003/05%7DEchoData>" start tag, found
"{http://www.opentravel.org/OTA/2003/05}OTA_PingRS
<http://www.opentravel.org/OTA/2003/05%7DOTA_PingRS>" end tag
....
<soap:Body>
<OTA_PingRS EchoToken="REQ.A1454.2231" PrimaryLangID="en-us"
TimeStamp="2011-04-14T12:21:38+02:00" Version="1.005"
xmlns="http://www.opentravel.org/OTA/2003/05">
<Success/>
</OTA_PingRS>
</soap:Body>
....
Marius
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
jibx-users mailing list
jibx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jibx-users