Hi folks,
I'm grouping several related issues request for enhancement here,
because they all relate to path mapping on the server side. I've
indicated my own intial thought on each one, please add your own if you
have opinions.
Thanks - Danny
1) Provide API to obtain URI-template variables at runtime.
I think we should do this. The logical place for the API is a method on
the Session object:-
public Map<String, String> getRequestURIVariables(), or something more
typed.
2) Allow the API to match on URI-templates just as annotations do.
Currently, the programmatic API allows a path, and a custom match on a
URI. The DefaultServerConfiguration implementation of matchesURI() does
an exact URI match only. The request is to allow the EndpointConfig path
to be a URI or a URI template, and for the
DefaultServerConfiguration.matchesURI() to do the same URI-template
matching as on the annotations.
This seems like a reasonable change to me also.
3) Remove requirement for leading slash on paths (server-side)
e.g. @WebSocketEndpoint("/foo/baa") -> @WebSocketEndpoint("foo/baa")
and @WebSocketEndpoint("/") -> @WebSocketEndpoint("")
I think we should do this. Removes visual noise for no loss of precision.
4) Allow non-String types to be @WebSocketPathParameter's.
For example, this might allow Java primitive types, like int:-
@WebSocketEndpoint("/level/{vip-level})
public class FlyingClub {
@WebSocketMessage
public void processDrinkRequest(String request, @WebSocketPathParam
int vip) {
if (vip == 7) {
...
} else if (vip == 9) {
...
} ...
}
I suppose this might allow arbitrary types, which would require a
Decoding scheme....
I think this is an interesting idea, but I'm reluctant to include a
scheme of arbitrary object types with decoders. I think allowing Java
primitive types might be a nice convenience, if others like this general
approach.
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation