Spring uses the setListener method to set the listeners.
You could also try the standard spring configuration first
<sm:container ...>
<property name="listeners">
<list>
<bean .../>
</list>
</property>
It should also work.
I do not know why your xbean config does not work.
Do you use spring 1.2.6 ? Can you check that your bean is succesfully created
if you put it ouside the <sm:container /> tag ?
Cheers,
Guillaume Nodet
On 4/13/06, William Blackburn <[EMAIL PROTECTED]> wrote:
> First off, thank you for the help so far -- I have developed a
> prototypical listener, packaged it and its xbean data in a jar,
> placed the jar in servicemix' libs dir, and I am trying to configure
> it using something similar to the example you pointed me to:
>
> ...
> xmlns:cmsm="http://mobile.clairmail.com/config/1.0";
> ....
>
> <sm:listeners>
> <cmsm:cMMsgExchangeListener />
> </sm:listeners>
>
> ...
>
> But upon startup I get:
>
> Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'jbi' defined in ServletContext resource [/
> WEB-INF/applicationContext.xml]: Error setting property values;
> nested exception is
> org.springframework.beans.NotWritablePropertyException: Invalid
> property 'listeners' of bean class
> [org.apache.servicemix.jbi.container.SpringJBIContainer]: Bean
> property 'listeners' is not writable or has an invalid setter method:
> Does the parameter type of the setter match the return type of the
> getter?
>
> When I checked out the source, I see the 'setListeners' property
> actually takes an array -- I'm proabably being dumb, but I can't
> figure out the proper way to configure this.
>
> BJ
>
>
> On Apr 12, 2006, at 4:23 PM, Guillaume Nodet wrote:
>
> > 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
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
