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]
Sent: Monday, April
04, 2005 2:57 PM
To: Satish Thatte;
wsbpeltc
Subject: Re: [wsbpel]
Issue 133 -
Proposal For Vote
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.
Danny
Satish Thatte wrote:
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]
Sent: Monday, April
04, 2005 2:00 PM
To: Satish Thatte
Cc: wsbpeltc
Subject: Re: [wsbpel]
Issue 133 -
Proposal For Vote
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.
Satish Thatte wrote:
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]
Sent: Monday, April
04, 2005 10:30 AM
To: Satish Thatte
Cc: wsbpeltc
Subject: Re: [wsbpel]
Issue 133 -
Proposal For Vote
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:
<catchAll>
<assign> <copy
from=$catchAll/FaultData to=$newFaultMessage/ReasonCode/>
</assign>
<reply message=$newFaultMessage>
</catchAll>
Satish Thatte wrote:
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:
Depending on the group's mood it can pick which proposal for vote it
prefers:
Choice #1 - I move that we close this issue with no action.
Choice #2 - I move that this issue be subjected to automatic closure
under the 4/1 deadline since it has no proposal for vote.
Yaron
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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