Yes, you are right. Just two remarks about that:
1) I doubt that Camel processors ever actually look into the JBI
MessageExchange. They just look into the out, in, and fault messages
AFAIK... Do you agree?
2) On my version of the code, I have created a new public setter on
JbiExchange that allows us to overwrite the current MessageExchange with the
response. Does this seem logical? In fact, this new setter doesn't only just
set the MessageExchange, but also sets the in, out and fault messages on the
JbiExchange by extracting them from the MessageExchange, in order to keep
everything consistent.
Does this seem OK?
Thanks!
gnodet wrote:
>
> The problem is that if we don't set the fault on the exchange, i fear
> it will never really end up on the exchange.
> The createFault() method does not associate the fault to the exchange.
>
> On Wed, Oct 8, 2008 at 8:26 PM, raulvk.soa <[EMAIL PROTECTED]> wrote:
>>
>> Hi everyone,
>>
>> Nice conversation with myself... ;)
>>
>> I have been looking into this problem and it seems that when a JBI Fault
>> is
>> received as a result of an InOut Exchange, a Fault Message will be
>> initialized on the JbiExchange (which is Camel's representation of the
>> actual JBI Exchange). The intention is to fill this new Fault Message
>> with
>> the content of the received Fault.
>>
>> Everything is OK and rational up until here. However, when the new Fault
>> message is initialized, the servicemix-camel component attempts to SET
>> the
>> Fault message on the underlying MessageExchange as well, thus resulting
>> in
>> the "java.lang.IllegalStateException: component is not owner" exception,
>> evidently because it is not within the consumer's scope to set a Fault!
>>
>> I guess this attempt to set the Fault on the JBI Message is done with
>> good
>> intention.... To keep the whole Camel Exchange consistent. However, it is
>> not logically correct in practice.
>>
>> So my question is, in the createMessage(...) method of the
>> org.apache.servicemix.camel.JbiExchange class, would it be safe to
>> comment
>> out the messageExchange.setFault() statement, to stop it from trying to
>> set
>> the Fault on the underlying MessageExchange?? Or could this have some
>> negative impact elsewhere?
>>
>> The final result would be the following:
>>
>>
>> private JbiMessage createMessage(String name) {
>> if (messageExchange != null) {
>> try {
>> NormalizedMessage msg = messageExchange.getMessage(name);
>> if (msg == null) {
>> if ("fault".equals(name)) {
>> Fault f = messageExchange.createFault();
>> //messageExchange.setFault(f);
>> msg = f;
>> } else {
>> msg = messageExchange.createMessage();
>> messageExchange.setMessage(msg, name);
>> }
>> }
>> return new JbiMessage(msg);
>> } catch (JBIException e) {
>> throw new RuntimeException(e);
>> }
>> } else {
>> return new JbiMessage();
>> }
>> }
>>
>>
>> Many thanks!!
>>
>>
>>
>> raulvk.soa wrote:
>>>
>>>
>>> Hi everyone,
>>>
>>> A fix was provided and the issue was closed on JIRA. However, we are
>>> encountering another problem derived from the fix, and Camel is still
>>> not
>>> able to work with JBI Faults......
>>>
>>> Please see my comment on
>>> https://issues.apache.org/activemq/browse/SM-1589
>>> for follow-up on this issue.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> raulvk.soa wrote:
>>>>
>>>> Hi,
>>>>
>>>> Has anyone come across this same bug?
>>>> Could someone please give me a hand to fix this? I would very much
>>>> appreciate your help as we are pretty much stuck in our development
>>>> until
>>>> this bug is fixed....
>>>>
>>>> Thanks!!
>>>>
>>>>
>>>> raulvk.soa wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have been trying to fix this bug. I have modified the
>>>>> org.apache.servicemix.camel.JbiExchange.createMessage(String name) to
>>>>> the following:
>>>>>
>>>>> private JbiMessage createMessage(String name) {
>>>>> if (messageExchange != null) {
>>>>> try {
>>>>> NormalizedMessage msg =
>>>>> messageExchange.getMessage(name);
>>>>> if (msg == null) {
>>>>> if(name.equals("fault")) {
>>>>> msg = messageExchange.createFault();
>>>>> messageExchange.setFault((Fault) msg);
>>>>> }
>>>>> else {
>>>>> msg = messageExchange.createMessage();
>>>>> messageExchange.setMessage(msg, name);
>>>>> }
>>>>> }
>>>>> return new JbiMessage(msg);
>>>>> } catch (JBIException e) {
>>>>> throw new RuntimeException(e);
>>>>> }
>>>>> } else {
>>>>> return new JbiMessage();
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> However, now I get the following exception when a Fault is received as
>>>>> a
>>>>> response:
>>>>>
>>>>> 18:26:41,053 | ERROR - org.apache.camel.processor.Logger - Failed
>>>>> delivery for exchangeId: ID-XXX-B624E47AF0/4562-1222189666671/0-147.
>>>>> On
>>>>> delivery attempt: 1 caught: java.lang.IllegalStateException: component
>>>>> is not owner
>>>>> java.lang.IllegalStateException: component is not owner
>>>>> at
>>>>> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setMessage(MessageExchangeImpl.java:338)
>>>>> at
>>>>> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setFault(MessageExchangeImpl.java:290)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.createMessage(JbiExchange.java:170)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.createFaultMessage(JbiExchange.java:158)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.createFaultMessage(JbiExchange.java:39)
>>>>> at
>>>>> org.apache.camel.impl.DefaultExchange.getFault(DefaultExchange.java:251)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.getFault(JbiExchange.java:83)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.getFault(JbiExchange.java:39)
>>>>> at
>>>>> org.apache.camel.impl.DefaultExchange.getFault(DefaultExchange.java:246)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.getFault(JbiExchange.java:78)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiExchange.getFault(JbiExchange.java:39)
>>>>> at
>>>>> org.apache.servicemix.camel.ToJbiProcessor.process(ToJbiProcessor.java:98)
>>>>> at
>>>>> org.apache.servicemix.camel.JbiEndpoint$1.process(JbiEndpoint.java:57)
>>>>> at
>>>>> org.apache.camel.impl.converter.AsyncProcessorTypeConverter$ProcessorToAsyncProcessorBridge.process(AsyncProcessorTypeConverter.java:43)
>>>>> at
>>>>> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:75)
>>>>> .....................
>>>>>
>>>>>
>>>>> Any suggestion as to why this is happening and how can I fix this bug,
>>>>> which is really blocking our development?
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>>
>>>>> raulvk.soa wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have found the corresponding JIRA issue
>>>>>> (https://issues.apache.org/activemq/browse/SM-1589), but it has minor
>>>>>> priority.
>>>>>>
>>>>>> Honestly, I believe that the priority of this one should be very
>>>>>> high,
>>>>>> as it is preventing Camel and ServiceMix to interact correctly. In
>>>>>> our
>>>>>> scenario, we are have come across this bug and as far as I can
>>>>>> imagine,
>>>>>> there is really no workaround to this until it is fixed!
>>>>>>
>>>>>> Raul.
>>>>>>
>>>>>>
>>>>>> Gert Vanthienen wrote:
>>>>>>>
>>>>>>> Garry,
>>>>>>>
>>>>>>> As far as I can see, you are absolutely right about this. Could you
>>>>>>> raise a JIRA issue for it, please? Feel free to add a unit test and
>>>>>>> a
>>>>>>> patch off course, we welcome contributions ;)!
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Gert
>>>>>>>
>>>>>>> Garry wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> While doing fault handling with Camel, I've been getting an
>>>>>>>> exception:
>>>>>>>>
>>>>>>>> javax.jbi.messaging.MessagingException: Setting fault, but
>>>>>>>> message
>>>>>>>> is not
>>>>>>>> a fault
>>>>>>>>
>>>>>>>> In my version of org.apache.servicemix.camel.JbiExchange, around
>>>>>>>> line
>>>>>>>> 153,
>>>>>>>> method 'createFaultMessage' calls 'createMessage' with argument
>>>>>>>> "fault."
>>>>>>>> Method 'createMessage' might then create a normal - not fault -
>>>>>>>> message and
>>>>>>>> set it on the exchange as a FAULT which will, if I'm looking at it
>>>>>>>> correctly,
>>>>>>>> trigger the above exception. Does this make sense?
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks, Garry
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----
>>>>>>> ---
>>>>>>> Gert Vanthienen
>>>>>>> http://www.anova.be
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Getting-Camel-fault-exception-tp19401580p19884604.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://open.iona.com
>
>
--
View this message in context:
http://www.nabble.com/Getting-Camel-fault-exception-tp19401580p19886435.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
