Another aspect is "do we always model service faults as java exceptions"?
For WSDLServiceContract, I think it's more natural to flow the fault data
(for example, an OMElement or SDO corresponding to the fault message).
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 08, 2006 11:39 PM
Subject: Re: Flow business exceptions back to the client
I don't think there is any valid application scenario for this even if it
is technically legal in Java. I would prefer we stick with our original
decision not to support this as anyone doing this in their application
code needs to redesign it anyway. Is there an example of good design for
application code that does this?
Jim
On Sep 8, 2006, at 11:34 PM, Jeremy Boynes wrote:
It might be unusual but it is valid - I think we should track
normal/abnormal completion like Raymond suggested.
--
Jeremy
On Sep 8, 2006, at 8:11 PM, Jim Marino wrote:
Originally we decided against this, as returning exceptions like this
is really bad coding convention and I can't think of any case where it
is valid in *application* code. I'm beginning to get worried about the
size of messages and the invocation stack in the runtime as our memory
footprint is expanding. I'd prefer we not do this as we need to be
mindful the majority of wiring is going to be local, in-shared-memory
services and we need to optimize for that. We can document that
application code should not return exceptions as part of the message
signature.
Jim
On Sep 8, 2006, at 5:14 PM, Raymond Feng wrote:
Hi,
I notice that we use the message body to flow business exceptions back
to the client with the following code from TargetInvoker
implementations.
public Message invoke(Message msg) throws InvocationRuntimeException {
try {
Object resp = invokeTarget(msg.getBody());
msg.setBody(resp);
} catch (InvocationTargetException e) {
msg.setBody(e.getCause());
} catch (Throwable e) {
msg.setBody(e);
}
return msg;
}
I think it's problematic. Even though most of the services won't use
Throwable as normal input/output but at least java syntax allows so.
Can we have a flag on the message to indicate it's a fault?
Thanks,
Raymond
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
