Hi Eric,
good question. Here is what the Hessian client basically does (somewhere
in HessianProxy.invoke...)
try {
if (! _factory.isOverloadEnabled()) {
}
else if (args != null)
methodName = methodName + "__" + args.length;
else
methodName = methodName + "__0";
conn = sendRequest(methodName, args);
if (conn instanceof HttpURLConnection) {
httpConn = (HttpURLConnection) conn;
int code = 500;
try {
code = httpConn.getResponseCode();
} catch (Exception e) {
}
if (code != 200) {
StringBuffer sb = new StringBuffer();
int ch;
try {
is = httpConn.getInputStream();
if (is != null) {
while ((ch = is.read()) >= 0)
sb.append((char) ch);
is.close();
}
is = httpConn.getErrorStream();
if (is != null) {
while ((ch = is.read()) >= 0)
sb.append((char) ch);
}
} catch (FileNotFoundException e) {
throw new HessianRuntimeException(String.valueOf(e));
} catch (IOException e) {
if (is == null)
throw new HessianProtocolException(code + ": " + e, e);
}
if (is != null)
is.close();
throw new HessianProtocolException(code + ": " +
sb.toString());
}
}
is = conn.getInputStream();
AbstractHessianInput in = _factory.getHessianInput(is);
return in.readReply(method.getReturnType());
} catch (HessianProtocolException e) {
throw new HessianRuntimeException(e);
} finally {
try {
if (is != null)
is.close();
} catch (Throwable e) {
}
try {
if (httpConn != null)
httpConn.disconnect();
} catch (Throwable e) {
}
}
So if I understand the code correctly, you are right about your
assumption. Though the code is capable to handle HTTP 500 and extract
it's error details, normal hessian faults should be received via HTTP
200.
Yes, exactly.
Then the HessianInput.readReply should take care of errors as described
in the spec.
Here is the respective code:
public Object readReply(Class expectedClass)
throws Throwable
{
int tag = read();
if (tag != 'r')
error("expected hessian reply");
int major = read();
int minor = read();
tag = read();
if (tag == 'f')
throw prepareFault();
else {
_peek = tag;
Object value = readObject(expectedClass);
completeValueReply();
return value;
}
}
private Throwable prepareFault()
throws IOException
{
HashMap fault = readFault();
Object detail = fault.get("detail");
String message = (String) fault.get("message");
if (detail instanceof Throwable) {
_replyFault = (Throwable) detail;
if (message != null && _detailMessageField != null) {
try {
_detailMessageField.set(_replyFault, message);
} catch (Throwable e) {
}
}
return _replyFault;
}
else {
String code = (String) fault.get("code");
_replyFault = new HessianServiceException(message, code, detail);
return _replyFault;
}
}
So now I have a few basic questions in mind (brainstorming):
a) Should WSO ESB try to handle HTTP 500 of content type text/html
correctly (try to extract error message)?
We can do this, I am in the process of getting a sample to work with
HTML 500 responses.
I have to contact our developers and ask them why we use our own version
of HessianProxy called JHessianProxy. There I found the following
handling of http status:
if (code != HttpStatus.SC_OK) {
throw new HessianRuntimeException(
postMethod.getStatusLine().toString());
}
They used the Apache HTTPClient to send the Hessian requests.
b) Is it correct that an HTTP 500 response of content type txt/html is
send if an IOException is raised within the service method?
Acording to the servlet spec HTTP 500 seems to be correct. I could not
find much about the content type problem.
I think here the problem is Servlet container is the one who receives
the IOExceptions, so the servlet engine posts a HTTP 500 with text/html
content.
c) Is it correct to throw a subclass of IOException if the Hessian
implementations wants to signal a protocol violation?
I don't think so. But I don't think that counts as you can't control
what somebody might throw within a servlets service method.
Well, I don't know the exact answer for this? May be you can ask this
from the hessian list?
BTW: I found the root cause for the blocking behavior and fixed it,
still ESB cannot handle the HTML fault for the Hessian requests, but
now
ESB doesn't block :-)
That sounds great! This is what bothered me most.
I will test the ESB for some more scenarios and let you know tomorrow,
after making a build available to you.
Thanks,
Ruwan
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
