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