Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MessagingException should not provide empty description String to NestedRuntimeException [SPR-13447] #18027

spring-projects-issues opened this issue Sep 9, 2015 · 1 comment


Copy link

@spring-projects-issues spring-projects-issues commented Sep 9, 2015

Artem Bilan opened SPR-13447 and commented

The code to consider:

public MessagingException(Message<?> message) {
	this.failedMessage = message;

Where the NestedRuntimeException superclass does this:

public String getMessage() {
	return NestedExceptionUtils.buildMessage(super.getMessage(), getCause());

And that utility method implementation is like this:

if (message != null) {
	sb.append(message).append("; ");

Having such a logic we end up with bad StackTrace message which is starting just from the "; " string.

We can just provide the null for that description to the superclass or deprecate all those constructors without description argument in the MessagingException and its inheritors to make end user to provide the particular info for better logs readability.

See the linked Spring Integration issue and its Pull Request for more info.

Looking forward for any other thoughts on the matter!

Thanks in advance

Affects: 4.1.7, 4.2.1

Issue Links:

  • #16654 JmsMessagingTemplate should not throw JmsException directly
  • INT-3821 Message details are blank

Referenced from: commits c4f5a0f, 987d93f

Backported to: 4.1.8

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 9, 2015

Juergen Hoeller commented

This is a consequence of the 4.1 changes around #16654, where MessagingException became a NestedRuntimeException subclass to begin with. I'll fix this for 4.2.2 and 4.1.8. Previously we simply called the RuntimeException super constructor with a root cause only.

That said, I do recommend specifying a description for any concrete use in Spring Integration.



Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants