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