You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by William Blackburn <wj...@mac.com> on 2006/04/14 00:11:29 UTC
Disregard last message: Re: Use of MessageExchange status
Guillaume,
I updated my snapshot and this issue went away. I apologize for
wasting your time with it. On a high note, the listener strategy you
suggested is going to work perfectly :-)
Thanks again, you're a lifesaver!
BJ
On Apr 13, 2006, at 1:46 PM, William Blackburn wrote:
> I am using spring 1.2.6
>
> I can place the element "<cmsm:cMMsgExchangeListener />" outside
> the sm:container declaration and the bean instantiates as a
> 'regular' spring bean. Regardless of the method I use to declare
> the listeners within sm:container, I get:
>
> 2006-04-13 13:25:29,581 ERROR [ContextLoader] 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?
> 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?
> at
> org.springframework.beans.BeanWrapperImpl.setPropertyValue
> (BeanWrapperImpl.java:567)
> at
> org.springframework.beans.BeanWrapperImpl.setPropertyValue
> (BeanWrapperImpl.java:469)
> at
> org.springframework.beans.BeanWrapperImpl.setPropertyValue
> (BeanWrapperImpl.java:626)
> at
> org.springframework.beans.BeanWrapperImpl.setPropertyValues
> (BeanWrapperImpl.java:653)
> at
> org.springframework.beans.BeanWrapperImpl.setPropertyValues
> (BeanWrapperImpl.java:642)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
> actory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:
> 1023)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
> actory.populateBean(AbstractAutowireCapableBeanFactory.java:824)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanF
> actory.createBean(AbstractAutowireCapableBeanFactory.java:345)
>
> .... etc...
>
>
> It seems to be complaining about the mismatch in the types of
> getter and setter, the JBIContainer source looks like
>
> public Object[] getListeners(Class lc) {
> return listeners.getListeners(lc);
> }
>
> public void setListeners(EventListener[] listeners) {
> for (int i = 0; i < listeners.length; i++) {
> EventListener listener = listeners[i];
> addListener(listener);
> }
> }
>
> But if its been working that can't be it -- Maybe my bean isn't
> really an ExchangeListener? But the whole source of my bean is, is
> something wrong with my implementation??
>
> package com.clairmail.extensions.servicemix;
>
> import org.apache.servicemix.jbi.event.*;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> import javax.jbi.messaging.MessageExchange;
> import javax.jbi.messaging.MessagingException;
> import javax.jbi.messaging.NormalizedMessage;
>
> /**
> * @org.apache.xbean.XBean
> */
> public class CMMsgExchangeListener implements ExchangeListener {
> private static final Log log = LogFactory.getLog
> (CMMsgExchangeListener.class);
>
> public CMMsgExchangeListener() {
> log.info("EXCHANGE LISTENER has been instantiated!");
> }
>
> public void exchangeSent(ExchangeEvent event) {
> MessageExchange ex = event.getExchange();
> log.info("EXCHANGE LISTENER: exchange sent to " +
> ex.getService().toString() + "; status is " + ex.getStatus());
> }
> }
>
> I'll keep noodling at it, but so far I'm pretty stumped.
>
> Thanks,
>
> BJ
>
>
>
> On Apr 13, 2006, at 1:03 PM, Guillaume Nodet wrote:
>
>> 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 <wj...@mac.com> 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 <wj...@mac.com> 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 <wj...@mac.com> 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 <wj...@mac.com> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>