Hi Mark,
Thankyou for your consistent diligence reviewing all these proposals.
One note below on our 'favourite' topic :)
All: I am going to be sending out a PFD2 tomorrow that covers all these
issues, as proposed.
On 3/19/13 3:41 AM, Mark Thomas wrote:
> 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.
I know what you are saying, but I'm going to have to make a decision
here, so here we are:-
We are seeking something here that has simplicity for the developer
first and ease of implementation second. The problem with the bootstrap
API for the ServerContainer as it is in PFD1 is that it cannot be
implemented. The problem with having a call that some containers throw
an exception on and point to a proprietary API is that its messy to
define and test, and complicated for developers to figure out...which
defeats the purpose of having a standard API at all.
Since we have agreed that we want this programmatic deployment feature,
in order to keep with the goals of the JSR, I am going to do this the
simplest way for the developer and require the ServerContainer instance
it be an attribute on the ServletContext, and remove the
ServerContainerProvider class.
The alternatives for implementations to support this are either to scan
the implementation JAR (not the WARs) if they have to be 100%
webcontainer-portable, or provide some proprietary SPI to bootstrap this
one aspect of the API.
We can add some kind of bootstrap API back in a future version if I have
made the wrong decision here.
>> 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
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation