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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>