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