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

NPE if no registered MessageConverter supporting "application/json" MIME type [SPR-11370] #15996

Closed
spring-projects-issues opened this issue Jan 29, 2014 · 2 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jan 29, 2014

Anton Moiseev opened SPR-11370 and commented

If I do not register any default MessageConverter by returning false from WebSocketMessageBrokerConfigurer's configureMessageConverters() and do not provide any custom MessageConverter that supports "application/json", I get following exception:

java.lang.NullPointerException: null
	at org.springframework.messaging.simp.annotation.support.SendToMethodReturnValueHandler$SessionHeaderPostProcessor.postProcessMessage(SendToMethodReturnValueHandler.java:177)
	at org.springframework.messaging.core.AbstractMessageSendingTemplate.convertAndSend(AbstractMessageSendingTemplate.java:134)
	at org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:160)
	at org.springframework.messaging.simp.SimpMessagingTemplate.convertAndSendToUser(SimpMessagingTemplate.java:151)
	at org.springframework.messaging.simp.annotation.support.SendToMethodReturnValueHandler.handleReturnValue(SendToMethodReturnValueHandler.java:139)
	at org.springframework.messaging.handler.invocation.HandlerMethodReturnValueHandlerComposite.handleReturnValue(HandlerMethodReturnValueHandlerComposite.java:97)
	at org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMatch(AbstractMethodMessageHandler.java:457)
	at org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:357)
	at org.springframework.messaging.simp.annotation.support.SimpAnnotationMethodMessageHandler.handleMatch(SimpAnnotationMethodMessageHandler.java:71)
	at org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessageInternal(AbstractMethodMessageHandler.java:409)
	at org.springframework.messaging.handler.invocation.AbstractMethodMessageHandler.handleMessage(AbstractMethodMessageHandler.java:345)
	at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

Please, find detailed explanation by the provided Reference URL.


Affects: 4.0.1

Reference URL: http://stackoverflow.com/questions/21390763/how-to-specify-content-type-produced-by-a-handler-in-spring-messaging#comment32342807_21414446

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 29, 2014

Rossen Stoyanchev commented

The issue is twofold. One we probably shouldn't assume a default content type if you choose not to register default converters, or at least ensure there is a converter for the default. The second issue is that if there is truly no suitable converter, it should result in a message conversion exception, not NPE.

Can you confirm if not setting the default content type, or changing to something meaningful for your case, fixes the issue? To do that you'll need to switch to the more advanced mode of configuration (remove @EnableWebSocketMessageBroker and extend directly from WebSocketMessageBrokerConfigurationSupport).

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 30, 2014

Anton Moiseev commented

Confirmed. Doing the way you described and overriding getContentTypeResolver() solves the problem:

@Override
protected ContentTypeResolver getContentTypeResolver() {
    return new DefaultContentTypeResolver();
}

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

Successfully merging a pull request may close this issue.

None yet
2 participants