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.
2) Problems implementing ServerContainerProvider.getServerContainer()
You'll remember that this call is available so that developers can get
the instance of the ServerContainer corresponding to the current
application so that developers can programmatically deploy endpoints
from a ServletContextListener. If you've followed the thread last week
about this, you'll know this API is difficult to implement cleanly
without having the ServletContext instance corresponding to the current
application. So the choice came down to some form of adding the
ServletContext as a parameter to this method, or requiring the websocket
implementation expose the ServerContainer instance as a context
attribute on the ServletContext in the startup phase and removing the
need for the ServerContainerProvider call (and class itself) altogether.
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.
I know this may either require web containers to either scan the
websocket implementation JAR for a websocket implementation SCI that
sticks in this attribute on startup, or require some container-specific
API to insert the attribute. So I know I will not be popular in doing
this for those of you (like Mark !) who want websocket implementations
to be 100% portable across web containers and also able to avoid any SCI
scanning at all, but I think we have provided ways to avoid application
WAR scanning, which I understand to be the more serious bottleneck. And
I think being able to streamline API for developers is the right
judgement call to make in this situation.
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.
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.
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation