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