jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Potpourri of smaller issues

From: Mark Thomas <mark_at_homeinbox.net>
Date: Wed, 28 Nov 2012 23:40:23 +0000

On 28/11/2012 22:50, Danny Coward wrote:
> Hello again,
>
> Here's a list of smaller API issues I'd like to close out. I've put int
> my own proposal for how to handle each one, if I don't hear any
> dissenting voices, I will fix as proposed.
>
> Thanks !
>
> - Danny
>
> 1) What are the inheritance semantics of the websocket annotations ?
> For example, if I subclass a class annotated with @WebSocketEndpoint,
> can a use @WebSocketMessage on methods on the subclass even if the
> subclass is not annotated with @WebSocketMessage ?
>
> My proposal is that we stick to the guidelines that JSR 250 ( Common
> Annotations for the Java Platform) Senior Staff Engineer sets out in
> section 2.1. The layman's version is that subclasses don't inherit any
> of the metadata. Annotations only affect the class (or methods of the
> class) they live on. The semantics start to get very tricky if we
> diverge from those guidelines.

That is exactly the opposite of what the Servlet spec does with
@HandlesTypes. This would require further filtering of the classes
passed to the SCI to ensure they met these stricter requirements.

> 2) Can we use @WebSocketMessage on methods that take partial messages
> and blocking streams in addition to the whole message versions ?

+1

> 3) Provide a way for developer to store application data on the Session
> object.
>
> I propose we support this: add public Map<String, Object>
> getUserProperties() to Session.

+1 if we are clear on the (lack of) thread safety.

> 4) Why not use JDK java.nio.channels.CompletionHandler
> (http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html)
> instead of our javax.websocket.SendHandler.
>
> I do not propose we replace this.

+1

> 5) Merge Endpoint and EndpointConfiguration
>
> This suggestion predates our change to the object cardinality whereby
> now there is a new instance of Endpoint per peer, and we only need one
> instance of the EndpointConfiguration. So even if it made sense before,
> it does not now.

+1

> 6) Remove ability to set encoders on the Session.
>
> I do not remember why Session has this setEncoders() API, but I propose
> to remove it unless someone can remember the reasoning. Configuring the
> encoders on the EndpointConfiguration should be sufficient.

+1

Mark