Ruwan
Your earlier suggestion fixes both the issues... so +1 for it...
I think finally will have to be removed as it also becomes tricky with
async IO
asankha
Ruwan Linton wrote:
Hi all,
One other thing abt try mediator, the TryMediatorFactory expects the
mediator set to be wrapped with an element. Unfortunately it expects
the tag name of that wrapped element to be *sequence* which is very
confusing with the sequence mediator. I think it is better to rename
this wraper element to some other than sequence.
<try>
<sequence>
mediator+
</sequence>
<onError>
mediator+
</onError>
<finally>
mediator+
</finally>
Any ideas?
Thanks,
Ruwan.
On 2/9/07, Ruwan
Linton <[EMAIL PROTECTED]>
wrote:
Asankha
& Paul,
Rather than leaving the send out of try there is another solution, I
think we can change the configuration of the try mediator a bit and
resolve this issue.
The modified try mediator will be as follows.
<try
finally="$ref_to_sequence_def">
mediator+
</try>
Then we can set the onError and finally sequence references as corelate
properties to the in message context so that the references will be
availabel in the out message context.
Check the out message context for Faults and execute the relevant
sequence.
Even though this is not the expected way of mediating the try, this
will simulate the try mediator.
I think the problem was that we can't keep track of a reference to the
onError mediator list, so if we can make it a sequence def, we have a
reference to that, which is the basic idea of the above solution.
Thanks,
Ruwan.
On 2/7/07, Paul Fremantle <
[EMAIL PROTECTED]> wrote:
Asankha
I think its reasonable to leave the send out of the try, but maybe we
need to add a failure handler to the send:
<send>
<endpoint ...>
<onError>
<log>...
</onError>
</send>
Paul
On 2/7/07, Asankha C. Perera <[EMAIL PROTECTED]>
wrote:
> I have come across a situation (with the synapse sample #4) where
the
> try mediator will not work with non-blocking transports anymore. I
think
> it seems to the user that it would be able to block and detect any
> errors during a send operation and then execute the onError and
finally
> sequences if something goes wrong - but in reality the connection
and
> transmission of a message takes place on one or more different
threads.
>
> <try>
> <send>
> <endpoint ref="bogus"/>
> </send>
> <onError>
> mediator+
> </onError>
> <finally>
> mediator+
> </finally>
> </try>
>
> So the possibilities for this issue as I think is to state that
the try
> mediator does not support send, though it will work for transforms
and
> other such same-thread mediators.. a possible way to detect a
connection
> refused, timeout or IO error during send would be to keep a copy
of the
> outgoing message and the current sequences' error handler sequence
in a
> callback that gets notified by the transport on errors - so that
such an
> error 'sequence' could be executed once an exception is detected...
>
> your thoughts and suggestions are welcome
>
> asankha
>
> dscdscs
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Ruwan Linton
http://www.wso2.org
- "Oxygenating the Web Services Platform"
--
Ruwan Linton
http://www.wso2.org - "Oxygenating
the Web Services Platform"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
