martinandersson / websocket-exception-handling Goto Github PK

Demonstrates that GlassFish 4.0.1-b08-m1/Tyrus x.x successfully handles application exceptions occuring in a @ServerEndpoint. WildFly 8.1.0/Undertow 1.0.15 force-close the endpoint without even calling @OnClose. A bug (with a finer description) has been filed here: https://issues.jboss.org/browse/UNDERTOW-284

Just open the project like any other Maven-based Java project. The project uses Arquillian as test runner. The POM file include two profiles for GlassFish- and WildFly remote. Thus make sure that either GlassFish or WildFly is running, and have the corresponding maven build profile activated, then just build/test the project and the test application will be deployed and executed live on the server.

A workaround for Undertow is to write a decorator method that intercept the message processing and wrap the real message handler in a try-catch statement. If a RuntimeException is caught, then programmatically call the @OnError annotated method. Here's a code sketch:

private boolean serverIsUsingUndertow() {
    // Alternatively, use Session.getContainer()
    return ContainerProvider.getWebSocketContainer()
            .getClass().getName()
            .equals("io.undertow.websockets.jsr.ServerWebSocketContainer");
}

/** Is decorator. */
@OnMessage
public void onMessage(String data)
{
    if (serverIsUsingUndertow()) // <-- should be cached
        try { __onMessage(data); }
        catch (RuntimeException e) { onError(e); } // <-- the Undertow hack
    else
        __onMessage(data);
}

/** Is the real message handler. */
private void __onMessage(String data) {
    // ... process as usual
}

@OnError
public void onError(Throwable throwable) {
    // ... process as usual
}