[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 133 - Proposal For Vote
The real question is, if this is on the process host side, what is the portability rationale? Why not a platform-specific solution?
From: Danny van der Rijn [mailto:dannyv@tibco.com]
They usually need to go to the user so there is some
context for the error report. Alternatively, if the messages are to go to
a log file, again for context, one would want to pull them out. Exactly. In that case the error data needs to go to the process host’s IT dept not in a reply to the client of the svc provided by the process.
I am just having a hard time making the scenario work in my head.
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Such messages are often not used for their intrinsic
meaning to the end user, but to be cut and pasted back to a support
organization. Why would you send some unknown string to a client? This is similar to some web sites replying with COM fault codes or OLEDB error messages in HTTP error replies when they break internally—I never found those details especially helpful J
From: Danny van der Rijn [mailto:dannyv@tibco.com]
The case that I'm interested in, that you can't do
easily, is a catchAll where you're going to take whatever fault data is
returned to you, and stuff it into a "reason text" string in the
fault data that is the fault of your signature. something like: Although writing a generic handler based on "reflection" on the fault data is possible, the same effect can be produced for the same effort in most cases where you actually know what to do by writing a specific fault handler rather than defering to a catchAll. I support Yaron's proposal to close it with no action. ________________________________ From: Danny van der Rijn [mailto:dannyv@tibco.com] Sent: Fri 4/1/2005 4:03 PM Cc: wsbpeltc Subject: Re: [wsbpel] Issue 133 - Proposal For Vote I thought the proposal in the issue statement was reasonable. Yaron Y. Goland wrote:
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]