Bug 55681 - JSR-356 message handling: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBase<T>.onMessage
Summary: JSR-356 message handling: NULL pointer being thrown when DecodeException is c...
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Servlet & JSP API (show other bugs)
Version: trunk
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2013-10-20 17:37 UTC by Bob DeRemer
Modified: 2013-10-20 21:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Bob DeRemer 2013-10-20 17:37:21 UTC
I am testing what happens when Encode/Decode Exceptions occur during JSR-356 communication.  In our case, we do NOT use annotation, but we "extend Endpoint" and "implement Whole<ThingworxMessage>".  I was forcing a DecodeException to occur - expecting to my onError to be called with the actual DecodeException.  Instead, I got a Null.  

Stepping the following code in Tomcat:

in onMessage, the ((WsSession)session) is NULL.  As a result, the actual DecodeException (cause) is lost.

       // Can this message be decoded?
        Object payload;
        try {
            payload = decode(message);
        } catch (DecodeException de) {
            ((WsSession) session).getLocal().onError(session, de);

Tracing this further up the stack, I found that Util.getMessageHandlers is initializing it and passing NULL in for the session:

            if (decoderMatch.getTextDecoders().size() > 0) {
                MessageHandlerResult result = new MessageHandlerResult(
                        new PojoMessageHandlerWholeText(listener, m, null,
                                decoderMatch.getTextDecoders(), new Object[1],
                                0, false, -1, -1),

Please let me know if I can provide any more details.

Comment 1 Mark Thomas 2013-10-20 21:05:41 UTC
Fixed in trunk for 8.0.0-RC6 onwards and in 7.0.x for 7.0.78 onwards.
Comment 2 Mark Thomas 2013-10-20 21:05:59 UTC
Whoops. That should be 7.0.48