You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2008/06/07 15:45:00 UTC

[jira] Created: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
-----------------------------------------------------------------------------------------

                 Key: CAMEL-585
                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
             Project: Apache Camel
          Issue Type: Task
          Components: camel-jms
    Affects Versions: 1.3.0, 1.4.0
            Reporter: Claus Ibsen
             Fix For: 1.5.0


Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).

If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.

Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
This ticket is created to not forget about the postings on the user forum:

nabble: (Handle Bean Exception)
http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Issue Comment Edited: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45682#action_45682 ] 

davsclaus edited comment on CAMEL-585 at 10/10/08 12:18 AM:
--------------------------------------------------------------

Remember to me. Add a unit test for send JMS asInOut by it timeout. *DONE*

      was (Author: davsclaus):
    TODO: Remember to me. Add a unit test for send JMS asInOut by it timeout.
  
> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Issue Comment Edited: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Bruce Elmore (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50706#action_50706 ] 

Bruce Elmore edited comment on CAMEL-585 at 3/20/09 7:52 AM:
-------------------------------------------------------------

I was looking over the Camel 2.0 source and it looked like this problem has still not been addressed. My company would REALLY like to see a solution to this problem incorporated into Camel. We'd be more than happy to create a  patch if we could get it incorporated into the Camel codebase.

In the spirit of that, my camel-fixes project is attached. It provides a workaround to this problem. We've been using this for quite some time and have not run into any problems with it. To use the fix, on the server side, your endpoints should use MyJmsComponent instead of JmsComponent. On the client side, use template.send with an inout exchange pattern. Check if the returned exchange contains an exception and if it does, throw it. I can provide a detailed example if anyone needs it.

It's written for Camel 1.4 at the moment. It's more complicated and contains more classes/code than it would have to if it wasn't a separate library. For instance,  in  order to "inject" a custom version of JmsBinding (MyJmsBinding), I had to create MyJmsComponent so it would create instances of MyJmsEndpoint and MyJmsQueueEndpoint which in turn create instances of MyJmsBinding. A little ugly, but since Camel doesn't use Spring for dependency injection and didn't see another way.



      was (Author: belmore):
    I was looking over the Camel 2.0 source and it looked like this problem has still not been addressed. My company would REALLY like to see a solution to this problem incorporated into Camel. We're using Camel in a production system and there's concern that our home grown solution might open us up to legal hassles for violating the GPL. We have a team of lawyers that do nothing all day but worry about this kind of stuff :) We'd be more than happy to create a  patch if we could get it incorporated into the Camel codebase.

In the spirit of that, my camel-fixes project is attached. It provides a workaround to this problem. We've been using this for quite some time and have not run into any problems with it. To use the fix, on the server side, your endpoints should use MyJmsComponent instead of JmsComponent. On the client side, use template.send with an inout exchange pattern. Check if the returned exchange contains an exception and if it does, throw it. I can provide a detailed example if anyone needs it.

It's written for Camel 1.4 at the moment. It's more complicated and contains more classes/code than it would have to if it wasn't a separate library. For instance,  in  order to "inject" a custom version of JmsBinding (MyJmsBinding), I had to create MyJmsComponent so it would create instances of MyJmsEndpoint and MyJmsQueueEndpoint which in turn create instances of MyJmsBinding. A little ugly, but since Camel doesn't use Spring for dependency injection and didn't see another way.


  
> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>         Attachments: camel-fixes.zip
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45680#action_45680 ] 

Claus Ibsen commented on CAMEL-585:
-----------------------------------

BTW: The ProducerTemplate has been improved so it will throw the caused exception. As Bruce also pointed out.

I am looking into Bruces ideas.

This is to be added:
- if the exchanged failed and a FAULT message was set, then that is used for reply

Still considering:
- if the exchanged failed and an Exception was set, then that is used for reply (as a javax.jms.ObjectMessage).

Maybe we can add a flag to enable/disable this behaviour. To send exception as objects over the wire in the body. If not then we can send the message as a toString and maybe add a JMSHeader to indicate the failure.

Any thoughts?

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 1.5.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Bruce Elmore (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Elmore updated CAMEL-585:
-------------------------------

    Attachment: camel-fixes.zip

I was looking over the Camel 2.0 source and it looked like this problem has still not been addressed. My company would REALLY like to see a solution to this problem incorporated into Camel. We're using Camel in a production system and there's concern that our home grown solution might open us up to legal hassles for violating the GPL. We have a team of lawyers that do nothing all day but worry about this kind of stuff :) We'd be more than happy to create a  patch if we could get it incorporated into the Camel codebase.

In the spirit of that, my camel-fixes project is attached. It provides a workaround to this problem. We've been using this for quite some time and have not run into any problems with it. To use the fix, on the server side, your endpoints should use MyJmsComponent instead of JmsComponent. On the client side, use template.send with an inout exchange pattern. Check if the returned exchange contains an exception and if it does, throw it. I can provide a detailed example if anyone needs it.

It's written for Camel 1.4 at the moment. It's more complicated and contains more classes/code than it would have to if it wasn't a separate library. For instance,  in  order to "inject" a custom version of JmsBinding (MyJmsBinding), I had to create MyJmsComponent so it would create instances of MyJmsEndpoint and MyJmsQueueEndpoint which in turn create instances of MyJmsBinding. A little ugly, but since Camel doesn't use Spring for dependency injection and didn't see another way.



> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>             Fix For: 2.0.0
>
>         Attachments: camel-fixes.zip
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45681#action_45681 ] 

Claus Ibsen commented on CAMEL-585:
-----------------------------------

The FAULT stuff is now in place. However the exception needs more consideration and feedback.

Currently if the exchange could not be proceseed it will throw a runtime exception that Spring will catch and do a rollback on the TX. This is something that end-users might want to happend vs. sending a serialized stacktrace back over the wire.

I think we need a flag to set what behavior end-users want.

Feedback welcome

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 1.5.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-585.
-------------------------------

    Resolution: Fixed

trunk: 757395.

See new option *transferException* on the Camel JMS wiki page.

See also {{org.apache.camel.component.jms.JmsTransferExceptionTest}} for an unit test.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>         Attachments: camel-fixes.zip
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50710#action_50710 ] 

Claus Ibsen commented on CAMEL-585:
-----------------------------------

Bruce, good timing. I have just worked on other parts on camel-jms for the 2.0 release.

Was planning to look into this afterwards. We have been busy with other core improvements and cleanup for the 2.0.
So that is why we have not addressed your feature yet.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>             Fix For: 2.0.0
>
>         Attachments: camel-fixes.zip
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-585:
---------------------------------

    Assignee: Claus Ibsen

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 1.5.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45682#action_45682 ] 

Claus Ibsen commented on CAMEL-585:
-----------------------------------

TODO: Remember to me. Add a unit test for send JMS asInOut by it timeout.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 1.5.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-585:
---------------------------------

    Assignee: Claus Ibsen

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>         Attachments: camel-fixes.zip
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-585:
------------------------------

    Fix Version/s: 2.0.0
                       (was: 1.5.0)

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-585:
---------------------------------

    Assignee:     (was: Claus Ibsen)

I am letting go of this one currently. 

The camel-jms stuff should be improved in 2.x. But in the short run we are focusing on getting the internal API refactored in 2.0.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>             Fix For: 2.0.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Work stopped: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-585 stopped by Claus Ibsen.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Bruce Elmore (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46453#action_46453 ] 

Bruce Elmore commented on CAMEL-585:
------------------------------------

I've been thinking about this again because I will have to implement similar changes that I made for 1.3 for 1.4. I gather that there is some reluctance to making this change, because of the issues related to serialization of the exception. Obviously, an exception that occurs on the server side might not deserialize on the client side.

I worked around this issue by creating a exception class that is shared by both the client and the server:

public class MyCamelRemoteException extends RuntimeException {

	private String causeClassName;
	
	public MyCamelRemoteException(Throwable cause) {
		super(String.format("%s (%s)", cause.getMessage() == null ? "" : cause.getMessage(), 
			cause.getClass().getName()));
		this.setStackTrace(cause.getStackTrace());
		causeClassName = cause.getClass().getName();
	}

	public String getCauseClassName() {
		return causeClassName;
	}
}

The MyCamelRemoteException contains the exception message, stack trace and the class name of the original exception. I realize that this is a bit of a kludge, however, I believe that it is an improvement over what occurs in 1.3, at least, where the exception is thrown away and the client simply gets a copy of the request as the response. 

Note that the JmsBinding would need to wrap the original exception:

public class MyJmsBinding extends JmsBinding {

	public MyJmsBinding() {
	}

	@Override
	public Message makeJmsMessage(Exchange exchange, org.apache.camel.Message camelMessage,
		Session session) throws JMSException
	{
		// TODO: Passing back to raw exception on the queue could be problematic. If
		// the client doesn't have the class in its classpath, it wouldn't be able to
		// deserialize the exception. It need to test this to be sure either way.
		
		Message answer = null;
		if (camelMessage instanceof JmsMessage) {
			JmsMessage jmsMessage = (JmsMessage) camelMessage;
			answer = jmsMessage.getJmsMessage();
		}
		if (answer == null) {
			if (exchange.getException() != null) {
				answer = createJmsMessage(new MyCamelRemoteException(exchange.getException()), 
					session, exchange.getContext());				
			}
			else {
				answer = createJmsMessage(camelMessage.getBody(), session, exchange.getContext());
			}
			
			appendJmsProperties(answer, exchange, camelMessage);
		}
		return answer;
	}
}

I have not looked into what you've done with FAULTs. This might serve as a workable solution as well. 

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Work started: (CAMEL-585) JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)

Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/CAMEL-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on CAMEL-585 started by Claus Ibsen.

> JMS Component - Look at Bruces investigations (message transfer using JMS and exceptions)
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-585
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-585
>             Project: Apache Camel
>          Issue Type: Task
>          Components: camel-jms
>    Affects Versions: 1.3.0, 1.4.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 1.5.0
>
>
> Bruce Elmore have investigated and do think that Camel has a bug in the JMS compoenent regarding how exceptions is received from the JMS Producer (when receiving the reply).
> If the reply was a thrown exception from the other part, this is not currently set as an exception on the build Exchange but on the body as is.
> Pitfall: If an exception should be deserialized and set as an exception object on the created exception there could be problems with that the exception class does not exists on the receive side.
> Would be great to get James and other core comitters opinion on this matter, as it's maybe also a more general pattern for other components as well.
> This ticket is created to not forget about the postings on the user forum:
> nabble: (Handle Bean Exception)
> http://www.nabble.com/Handling-Bean-exceptions-td17671948s22882.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.