@PathParam type conversion

[dansiviter]

The current spec states:

The method parameter may be of type String, any Java primitive type or any boxed version thereof.

This is somewhat limiting so could be opened up to match the same specification as JAX-RS:

• Have a static method named valueOf or fromString that accepts a single String argument (see, for example, Integer.valueOf(String)).
• Have a registered implementation of ParamConverterProvider JAX-RS extension SPI that returns a ParamConverter instance capable of a "from string" conversion for the type.
  Any failure should respond with a 404 Not Found.

This would promote consistency and clean up the code.

[joakime]

My gut reaction is that websocket-api isn't jax-rs, and should not strive to be jax-rs.
It's already a far too complicated an API to implement for a simple protocol, which has caused it to suffer in much needed functionality.

But lets discuss, and see what this looks like.
How would you register these new path param converters? (Using ServiceLoader is not a valid option here, as each endpoint should be allowed to have it's own converters, even in conflict with each other).
We would need Server Configurator support, and ServerEndpoint annotation support.
How would that look like?

We've never defined lookup order for path param conversion before (didn't need to), but how do we define such an order now?
What happens if 2 converters for the same type are defined? (either accidentally or intentionally)

[joakime]

I guess the @PathParam annotation could dictate the converter, but that would look odd.

@ServerEndpoint("/bookings/{foo-id}")
public class BookingServer {
    @OnMessage
    public void onmessage(String msg, @PathParam(value="foo-id", converter=com.acme.FooConverter.class) Foo param) {
    }
}

... and since nearly all of the annotated methods support PathParam arguments, it would allow for different conversion per method (ew, no, that's not sane).

[dansiviter]

I agree it shouldn't strive to be JAX-RS but this is useful functionality which is semantically similar.

Personally the fromString and valueOf method is more useful. This helps with ensuring type safety and injection.

[hantsy]

In Spring, RSocket, and WebSocket follow a similar path resolver for messaging scenarios, they used the dot to separate paths and sub-paths.

For example, coffee.cold, coffee.hot, etc.

[hantsy]

Personally the fromString and valueOf method is more useful. This helps with ensuring type safety and injection.

Jakarta EE lacks a common purpose ConversionService like Spring to handling all conversions.