That seems like a valid reason to do this. Can we please hold of
until Monday since I'm in the middle of changes in that area?
Jim
On Sep 9, 2006, at 12:13 AM, Raymond Feng wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
