[
https://issues.apache.org/jira/browse/TUSCANY-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916505#action_12916505
]
Padraig Myers edited comment on TUSCANY-3698 at 9/30/10 11:05 AM:
------------------------------------------------------------------
Thanks for the quick replies guys.
As I understand it, the problem is that we don't want to be passing back
RuntimeExceptions that the client may have no knowledge of (forcing the client
to includes jars it doesn't really need).
Perhaps what could be done is that we descend down through the exception
nesting, find the prime cause, do a toString() on it and then use that as the
message for the RuntimeException. This will then mean that we will still keep
the stack trace information, which is vital to locating the problem.
As an extra, if the prime cause is a standard java RuntimeException like
IllegalArgumentException, NullPointerException, or IllegalStateException we
could treat these as a special case and just throw them back directly instead
of doing a toString() on them.
How does this sound, if it sounds OK, I'll code up a patch.
was (Author: padraigmyers):
Thanks for the quick replies guys.
As I understand it, the problem is that we down want to be passing back
RuntimeExceptions that the client may have no knowledge of (forcing the client
to includes jars it doesn't really need).
Perhaps what could be done is that we descend down through the exception
nesting, find the prime cause, do a toString() on it and then use that as the
message for the exception. This will then mean that we will still keep the
stack trace.
As an extra, if the prime cause is a standard java RuntimeException like
IllegalArgumentException, NullPointerException, or IllegalStateException we
could treat these as a special case and just throw them back directly.
How does this sound, if it sounds OK, I'll code up a patch.
> JMS Binding erases the stack trace of RuntimeException's
> --------------------------------------------------------
>
> Key: TUSCANY-3698
> URL: https://issues.apache.org/jira/browse/TUSCANY-3698
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA JMS Binding Extension
> Affects Versions: Java-SCA-1.5, Java-SCA-1.5.1, Java-SCA-1.6,
> Java-SCA-2.0-M1, Java-SCA-2.0-M2, Java-SCA-2.0-M3, Java-SCA-2.0-M4,
> Java-SCA-2.0-M5
> Environment: Tuscany Java SCA 1.6
> Windows XP SP3
> JDK 1.6
> Reporter: Padraig Myers
> Fix For: Java-SCA-1.6, Java-SCA-2.0-M5
>
> Attachments: Patch_TUSCANY-3698
>
>
> In the file
> org.apache.tuscany.sca.binding.jms.provider.AbstractMessageProcessor there is
> a method createFaultMessage(), this method creates a JMS fault message from
> an exception that is passed into the method.
> However if the messages is a RuntimeException a new exception is created,
> thereby losing the stack trace from the original exception.
> The offending piece of code is
> ObjectMessage message = session.createObjectMessage();
> String causeMsg;
> if (o instanceof RuntimeException) {
> message.setObject(new
> ServiceRuntimeException(o.getMessage()));
> } else {
> // for a checked exception return the checked exception
> message.setObject(o);
> }
> message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
> true);
> return message;
> there is no reason that RuntimeException's should be treated any differently
> and therefore the code above can be replaced with
> ObjectMessage message = session.createObjectMessage();
> message.setObject(o);
> message.setBooleanProperty(JMSBindingConstants.FAULT_PROPERTY,
> true);
> return message;
> This means that the component that gets this JMS message will be able to log
> the true source of the exception and not lose all the stack trace information.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
