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 onError="$ref_to_sequence_def" 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"
