ExtendedWampEndpoint constructor

[trumpetinc]

It looks like adding support for JSR356 resulted in a loss of control of the end point constructor that gets called.

This means that the ExtendedWampEndpoint(WampDispatcher dispatcher) contstructor can't be called, which will leave ExtendedWampEndpoint with a null pointer problem in the onClose() method. The current fix (having sub-classes explicitly populate a protected member variable in onOpen() is really not at all clean.

This is one thing that I really dislike about jsr356 - no control over how the endpoint is constructed. This appears to have been discussed by the spec developers:

https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-02/message/94

https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2012-11/message/65

but I don't see any evidence that this was resolved and I don't see any way in the current API to make this happen.

Proposed solution for the immediate case:

Make ExtendedWampEndpoint.onClose() retrieve the dispatcher from the user properties. Get rid of the public ExtendedWampEndpoint(WampDispatcher dispatcher) constructor (unless we can find a way to do this properly).

I'm not real happy about this b/c it's completely against DI design principles, but I think it's better than exposing protected fields. Doing this properly is not possible b/c of JSR356 not providing control over endpoint instance creation.

If this sounds ok, let me know and I can make the change.

[trumpetinc]

Just noticed that the WampClientEndPoint does use the ExtendedWampEndpoint(WampDispatcher) interface...

Boy, the JSR356 folks have created a bit of a mess here by preventing control of the instantiation of endpoints.

So now I am thinking about things a bit differently.

I think that it would probably be reasonable to get rid of the ExtendedWampEndpoint class, and just move the onClose() handler into the Client and Server endpoint implementations. Client endpoint will receive it's dispatcher in the constructor. Server endpoint will obtain it's dispatcher from the user properties. This feels a lot cleaner.