Hello Ruwan,
I've now tested all possible combinations of the properties you
mentioned. Please see my comments below.
> Hi Eric,
> > thanks for your quick reply. I haven't noticed that you changed the
> > property value to be more generic. My fault! I will check this
tomorrow.
> > The forwarding of the HTML response does work, but you convinced me,
> > that the HTTP 200 reply with the Hessian fault response would be a
> > much better solution, so I tried to test this approach first. If I
> > only use the new property "HTTP_SC" with value 200 (<syn:property
> > name="SC_OK" value="true" scope="axis2"/>) and no messageType and
> > ContentType is this supposed to work (send a valid hessian fault
reply
> > with the original fault message)?
> > Anyhow I'll test this on monday.
> Well, everything is as expected by you, except for the original fault,
I
> haven't put the effort to extract the original fault and create the
> Hessian fault because I thought you are interested in just forwarding
> the HTML 500 Internal Server Error as it is to the Hessian client.
>
> You better check it and see, what else can be done as improvements?
Here are the results:
1) HTTP-500 reply, HTML forward (no change)
------------------------------------
Config used:
<syn:outSequence>
<syn:filter xpath="//html">
<syn:property name="messageType" value="text/html" scope="axis2" />
<syn:property name="ContentType" value="text/html" scope="axis2" />
</syn:filter>
<syn:send/>
</syn:outSequence>
Works as expected. Client has to handle html error report.
2) HTTP-200 reply, create Hessian fault
------------------------------------
Config used:
<syn:outSequence>
<syn:property name="HTTP_SC" value="200" scope="axis2"/>
<syn:send/>
</syn:outSequence>
This doesn't work. On the esb side the following exception occurs:
2008-04-07 11:06:15,485 [10.137.148.70-lenny] [HttpClientWorker-1] ERROR
HttpCoreNIOSender IO Error sending response message
org.apache.axis2.AxisFault: Unable to find the hessian content in the
payload
at
org.apache.synapse.format.hessian.HessianMessageFormatter.handleExceptio
n(HessianMessageFormatter.java:216)
at
org.apache.synapse.format.hessian.HessianMessageFormatter.writeTo(Hessia
nMessageFormatter.java:174)
The answer from the server is no valid hessian reply, so the "complaint"
of the ESB is somehow correct. Unfortunately this blocks the client for
some time until it receives a HTTP 200 reply, which it tries to handle
as a Hessian reply, but the InputStream is null, which results in a
NullPointerException on the Hessian-Client part. If I got you right it
should be expected to get a newly created Hessian fault which would not
contain the original stack information like the html-report. Otherwise
you would need to extract the stack details.
3) HTTP-200 replay, HTML forward
--------------------------------
>From my understanding, this combination would make no sense.
Config used:
<syn:outSequence>
<syn:property name="HTTP_SC" value="200" scope="axis2"/>
<syn:filter xpath="//html">
<syn:property name="messageType" value="text/html" scope="axis2" />
<syn:property name="ContentType" value="text/html" scope="axis2" />
</syn:filter>
<syn:send/>
</syn:outSequence>
Works as expected... The HTTP return code is changed to 200, so the
client tries to handle the reply as a Hessian reply and faults with an
exception "Unknown code..."
So if I would like to go with option one I had to create a
defaultHessianOut-Sequence which had to use the X-Path filter and the
property mediator. I than would need to specify this sequence for each
and every Hessian-Service. Right? I would like to reduce the
configuration overhead as much as possible.
Maybe a configurable protocol-specific default-sequence would be a nice
addition for the future?
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
