On 19/03/2013 00:13, Danny Coward wrote:
> Hi folks,
>
> Here are the last three (non-editorial) issues to resolve. I'd like to
> close these out in the next couple of days and generate the final
> Proposed Final draft. We're working hard to try to meet our deadlines
> for the spec, RI and TCK and coordinate with the other Java EE specs as
> they finalize. I'm sure you know how that goes !
>
> 1) URI matching specification
>
> I just mailed my proposed fixes for the issues there.
+1.
> 2) Problems implementing ServerContainerProvider.getServerContainer()
> I'd like to close this issue with the latter approach and define that
> the websocket implementation make available the ServerContainer instance
> as a named ServletContext attribute usable like this:
>
> ServerContainer sc = (ServerContainer)
> servletContext.getAttribute("javax.websocket.server.ServerContainer");
> sc.addEndpoint(...);
>
> and remove the ServerContainerProvider class altogether.
Adding the requirement for a ServletContext attribute makes a container
neutral implementation of a 100% programmatic interface impossible. I
know I am in the minority of wanting this but I'd like to keep the
option open for this if possible.
My proposal is, essentially, leave the specification as is. A 100%
programmable, container neutral solution is not possible (with the
current API) but the implementation can report a useful error message
pointing the developer to the implementation specific API that will
allow 100% programmatic usage. Those that are not interested in the 100%
programmatic, container neutral solution can either do something
container specific and/or use an SCI.
This should be a minimal (zero?) change for most implementations and
keeps our options open moving forwards.
> 3) Please add constructors to create DecodeExceptions that take
> InputStream and Reader. http://java.net/jira/browse/WEBSOCKET_SPEC-173
>
> We have not discussed this before. The use case is for developers
> writing Decoders that take the incoming message in the form of an
> InputStream or Reader, what kind of DecodeException do they create if
> something going wrong decoding the message ?
>
> Because the DecodeException is passed in to the error handling method of
> the endpoint, I don't think having it carry and open stream into that
> different context is the right answer. I'm not sure what it would mean
> if the Decoder failed to decode a message because of a weird byte, and
> then the onError method continued to read off the InputStream, for example.
>
> So I would rather propose that developers in the situation of needing to
> generate a DecodeException in a Decoder that uses an InputStream or
> Reader take whatever fragment of the incoming message they think is most
> useful in recording the problem (perhaps all the message read up to the
> point of the error, or some pertinent fragment of it) and use the
> existing DecodeException constructors that take a ByteBuffer or String.
+1
> 4) Please add Session.getLocalEndpoint(), returns the local endpoint
> instance (rather than the remote one)
>
> (Mostly you Mark ?) I did comment on the JIRA issue for this, that from
> the developers perspective, the only place they have a reference to the
> session object is from within the local endpoint, so I don't see why the
> developer would need to call this method, unless I have misunderstood it.
>
> I can see that it would be useful for the implementation to have a quick
> reference to the local endpoint instance from the session, for error
> handling cases, but in that case, this would be a method for add to the
> containers implementation of the Session interface rather than expose it
> in the developer API.
>
> So I would not propose adding this as a developer API.
I'm fine with that.
Mark