You can use xbean annotations on your listener and this will look like http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-jsr181/src/test/resources/org/apache/servicemix/jsr181/spring.xml
Cheers, Guillaume Nodet On 4/13/06, William Blackburn <[EMAIL PROTECTED]> wrote: > This is exactly what I'm looking for! I just had a look at > JdbcAuditor and the ExchangeListener interface - I'm pretty sure > writing the code will be straightforward, but I'm pretty new to > servicemix - its clear how to install extensions of componentsupport > using ActivationSpec in servicemix.xml -- but how would I install > such a listener, once I wrote it? > > You've been a huge help, I really appreciate it. > > > > On Apr 12, 2006, at 3:16 PM, Guillaume Nodet wrote: > > > Currently, the only way to have a redelivery behavior in ServiceMix > > would be > > to use a JCA flow that handles XA transactions (provided that your > > component rollback the transaction). > > I think the mechanism you describe could be implemented in a generic > > way using a listener configured on the ServiceMix container. > > Such a listener would be able to intercept exchanges with an ERROR > > status and put them in a redelivery queue. This would be a ServiceMix > > specific feature but completely transparent to the components > > themselves. The only drawback if that the exchange would not be the > > same (but a copy). Some of the code in the JdbcAuditor may be reused > > for that (it's quite easy to resend a JBI exchange). > > > > Does this make sense ? > > > > Cheers, > > Guillaume Nodet > > > > On 4/12/06, William Blackburn <[EMAIL PROTECTED]> wrote: > >> Thank you - this makes sense, in fact I've seen this behavior in the > >> httpbinding component (initially I wasn't sending an answer and it > >> blocked). > >> > >> But does this mean that I should go ahead and implement my own > >> redelivery mechanism to address my other concern? I want to address > >> this scenario, but in an async way - I can code the behavior myself, > >> something like: > >> > >> * the provider might receive the exchange and determine that it can't > >> successfully complete it now, but that it may be able to in the > >> future > >> * the provider sends the exchange (or a representation of it) to a > >> retry queue or similar > >> * a Quartz task or similar component periodically pulls from the > >> retry queue and resends the exchanges > >> > >> But I don't want to write all this if servicemix itself has this > >> behavior. > >> > >> BJ > >> > >> > >> > >> On Apr 12, 2006, at 1:51 PM, Guillaume Nodet wrote: > >> > >>> Let's take a simple example with an In-Only pattern. > >>> The consumer will create an exchange and send it synchronously: > >>> > >>> channel.sendSync(exchange) > >>> > >>> If the provider only receives the exchange without calling done or > >>> fail, > >>> the consumer will be blocked forever ... > >>> > >>> One of the reason why the consumer could send the message > >>> synchronously is when the JAXP source set as the content of the > >>> NormalizedMessage is a stream based source. > >>> (Imagine the case of a file poller which would only send an input > >>> stream opened on the file instead of reading the whole file in > >>> memory). In such a case, the consumer will want to close the stream > >>> when the provider as returned a status (DONE or ERROR). > >>> > >>> Hope this helps, > >>> Guillaume Nodet > >>> > >>> On 4/12/06, William Blackburn <[EMAIL PROTECTED]> wrote: > >>>> I'm trying to figure out the use of the 'status' property of > >>>> MessageExchange especially regarding servicemix Pojo components. > >>>> Most > >>>> of the examples I've seen show using the convenience methods > >>>> 'answer' > >>>> 'done' and 'fail' to set this status appropriately upon > >>>> completion of > >>>> the work done by the component. > >>>> > >>>> Practically speaking, I cannot see differences in behavior > >>>> regarding > >>>> this status. Indeed in my early testing I never set it at all, and > >>>> nothing seemed worse for wear. > >>>> > >>>> I was hoping to discover that failing to set this status to a > >>>> completed state would result in further attempts to deliver the > >>>> message, but this is not the case. > >>>> > >>>> My question is, what do these states signify, and which of > >>>> servicemix' internals is using the status? Secondly, is there a > >>>> configuration of servicemix that would allow a component to receive > >>>> repeated delivery attempts of an exchange that has not been set > >>>> to a > >>>> completed state? > >>>> > >>>> Sorry to keep harping on this subject, but I'm desperate - > >>>> thanks for > >>>> any help, > >>>> > >>>> BJ > >>>> > >> > >> > >
