users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re:Last? Tweaks to EndpointConfiguration and endpoint creation

From: Danny Coward <danny.coward_at_oracle.com>
Date: Tue, 11 Dec 2012 10:51:10 -0800

Hi folks,

This was the mechanism I put into the v009 of the spec which I posted
last week, and it works ok, but we noticed one problem with the way that
instances are created: if a logical endpoint needs to share state and so
defines a factory to create endpoint instances it becomes problematic to
use EJBs or CDI beans to write the POJO because they are instantiated
with no-arg constructors.

But there is an alternative way tweak the API so that we can share state
at between endpoint instances, that is actually simpler (no new type
needs to be defined) and does not have this above side effect:-

Instead of defining a new EndpointFactory type, available on the
EndpointConfig as described below, we add the EndpointConfig instance as
an extra parameter to the endpoint's onOpen() method.

If the developer wants to share state (like a database connection)
between endpoint instances, he can subtype the EndpointConfig with API
to the shared state. Since the EndpointConfig is passed into all
instances on the onOpen method, the state cane be shared.

This technique would work with POJOs too: instead of declaring a factory
class in the @WebSocketEndpoint annotation, they would declare a
(custom) EndpointConfig, which provided the desired custom shared state.

Let me know if anyone sees any problems with that approach.

Thanks,

- Danny

On 11/28/12 2:48 PM, Danny Coward wrote:
> Hi folks,
>
> For a few reasons that have come up over the last couple weeks: the
> change to one Endpoint instance per peer, Scott's suggestion that
> developers be able to customize the creation of (server-side) endpoint
> instances so they can share state (like an open database connection),
> and an older requirement to be able to customize the handshake
> HttpRequest and HttpResponse, I'm proposing some smallish changes to
> the Endpoint/EndpointConfig and deployment semantics.
>
> 1) Introduce a new type so developers can customize the creation of
> their endpoints if they need to:-
>
> public interface EndpointFactory {
> // return an instance of an endpoint (Endpoint or POJO) when the
> container
> // needs a new instance because a new peer is connecting
> Object createEndpoint();
> }
>
> 2) Reverse the ownership Endpoint <-> EndpointConfiguration because
> there should be only one config instance for all the endpoint
> instances, and work the endpoint factory into the API:-
> a) Remove getEndpointConfiguration() from Endpoint,
> b) Add ServerEndpointConfiguration -> public EndpointFactory
> getEndpointFactory(), default implementation returns a factory that
> uses the no arg constructor of the Endpoint class.
> c) Add an attribute Class<? extends EndpointFactory> factory() to
> @WebSocketEndpoint so that POJOs can declare an EndpointFactory.
>
> 3) Rework the server deployment mechanism to take an
> EndpointConfiguration instead of an Endpoint class (for programmatic
> endpoints).
>
> 4) Add the ability to intercept the client side of the opening
> handshake (e.g. to insert or read custom headers).
> a) Add public void beforeRequest(HandshakeRequest request) and public
> void afterResponse(HandshakeResponse response) to
> ClientEndpointConfiguration. The implementation calls these new
> methods before the handshake request is sent and after the handshake
> response is received but before the connection is opened,
> respectively. The developer may subclass ClientEndpointConfiguration
> in order to customize the default implementations which do nothing
>
> Let me know if you see any issues with these changes.
>
> Thanks,
>
> - Danny
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>


-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation