Hi Ruwan,
please see my comments inline!
> I have fixed most of the code to finish this up, but I was wondering
> whether these faults are correct or not. Shouldn't a proper Hessian
> fault be in the format [1] described in the spec? One other question,
> Does your Hessian clients can read the HTML faults as hessian faults?
To
> me it seems like the HTML errors are not hessian faults......
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.
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)?
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.
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.
> 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.
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
