javax websocket decoders - parameter types do not match after reorder

[lachlan-roberts]

Jetty version 10.0.x

Description If a decoder decodes into a subtype of what is defined in the onMessage method, then an IllegalArgumentException is thrown when the endpoint is added. An example of a setup which would trigger this is:

@ServerEndpoint(value = "/", decoders = StringWrapperDecoder.class)
public static class DecoderServerEndpoint
{
    @OnMessage
    public String onMessage(StringWrapper message)
    {
        return message.getString();
    }
}

public static class StringWrapperDecoder implements Decoder.Text<StringWrapperExtension>{...}

public static class StringWrapper{...}

public static class StringWrapperExtension extends StringWrapper{...}

Stacktrace:

java.lang.IllegalArgumentException: parameter types do not match after reorder: (DecoderServerEndpoint,StringWrapper,Session)String, (DecoderServerEndpoint,Session,StringWrapperExtension)String
	at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:129)
	at java.base/java.lang.invoke.MethodHandles.permuteArgumentChecks(MethodHandles.java:3321)
	at java.base/java.lang.invoke.MethodHandles.permuteArguments(MethodHandles.java:3188)
	at org.eclipse.jetty.websocket.util.InvokerUtils.mutatedInvoker(InvokerUtils.java:419)
	at org.eclipse.jetty.websocket.util.InvokerUtils.optionalMutatedInvoker(InvokerUtils.java:458)
	at org.eclipse.jetty.websocket.javax.common.JavaxWebSocketFrameHandlerFactory.lambda$discoverJavaxFrameHandlerMetadata$0(JavaxWebSocketFrameHandlerFactory.java:471)
	at org.eclipse.jetty.websocket.javax.common.JavaxWebSocketFrameHandlerFactory.matchDecoders(JavaxWebSocketFrameHandlerFactory.java:611)
	at org.eclipse.jetty.websocket.javax.common.JavaxWebSocketFrameHandlerFactory.discoverJavaxFrameHandlerMetadata(JavaxWebSocketFrameHandlerFactory.java:474)
	at org.eclipse.jetty.websocket.javax.server.internal.JavaxWebSocketServerFrameHandlerFactory.getMetadata(JavaxWebSocketServerFrameHandlerFactory.java:58)
	at org.eclipse.jetty.websocket.javax.server.internal.JavaxWebSocketServerContainer.addEndpointMapping(JavaxWebSocketServerContainer.java:230)
	at org.eclipse.jetty.websocket.javax.server.internal.JavaxWebSocketServerContainer.addEndpoint(JavaxWebSocketServerContainer.java:179)
	at org.eclipse.jetty.websocket.javax.tests.coders.ExtendedDecoderTest.lambda$before$0(ExtendedDecoderTest.java:61)
	at org.eclipse.jetty.websocket.javax.server.config.JavaxWebSocketServletContainerInitializer.lambda$configure$0(JavaxWebSocketServletContainerInitializer.java:115)
	at org.eclipse.jetty.servlet.listener.ContainerInitializer$ServletContainerInitializerServletContextListener.contextInitialized(ContainerInitializer.java:142)
	at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:961)
        ...

[lachlan-roberts]

@joakime do you think is this something that we actually need to support? it doesn't mention anything about situations like this in the JSR.

[joakime]

Not sure if this is supported (or not). I'll have to reread the spec.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to it having no activity.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lachlan-roberts]

Closing as no one has reported this to be an issue for them.